What I saw was the DER encoding of the beginning of an X.509 certificate.
30 82 07 72 -- SEQUENCE, start of the cert {
30 82 07 1c -- SEQUENCE, start of the TBSCert {
a0 03 -- EXPLICIT TAG 0, optional version {
02 01 02 -- INTEGER, value 2 (for v3)
}
02 10 40 00 00 00 d1 bd cd 0d 49 bf 66 4c 00 ce 85 24 -- INTEGER, serialNumber
30 0d -- SEQUENCE, field signature, type SignatureAlgorithm {
06 09 2b 06 01 04 01 9c 56 01 02 -- OID, value 1.3.6.1.4.1.3670.1.2, previously mistakenly designated as hashalg
05 00 -- NULL, parameters
}
30 81 82 -- SEQUENCE OF, issuerName, here comes the different RDN {
31 13 -- SET OF, the first RDN {
30 11 -- SEQUENCE, the first AVA of this RDN, probably the only one based on sizes
06 0a 09 92 26 -- OID, but incomplete (the base64 ends here), starts by 0.9.2342 which is unusually used in a certificate, except maybe for a domainComponent composed of 3 letters (remaining space in the AVA)
[...]
2013/2/7
<jckidder@aep.com>
You are correct. That is one way
to add binary data using ldif. Maybe I misunderstood your last statement.
You said that you decoded the data and saw the begining of a certificate.
Did you see the actual certificate details or did you see the binary
representation of the certificate that you then decoded again in order
to get the certificate details?
-Jon C. Kidder
American Electric Power
Middleware Services
614-716-4970
Unless I'm mistaken, encoding binary data info base64
is the correct way to do when using LDIF files.
2013/2/7 <jckidder@aep.com>
I'm hoping you simply missed my point. The data presented is not
a binary encoded certificate. base64 encoded ASCII is not binary data.
userCertificate requires a binary encoded x.509 certificate.
-Jon C. Kidder
American Electric Power
Middleware Services
614-716-4970
Erwann Abalea <eabalea@gmail.com>
Sent by: openldap-technical-bounces@OpenLDAP.org
02/07/2013 10:06 AM
|
|
I disagree here.
Decoding the Base64 presented shows the start of a certificate. It looks
like it's a v3 certificate, with a serialNumber equal to 0x40000000d1bdcd0d49bf664c00ce8524,
but the hashalg is something private (OID 1.3.6.1.4.1.3670.1.2), which
is owned by Mr Pavlov Roman. We also have the very start of the issuerName.
2013/2/7 <jckidder@aep.com>
This is not a correctly encoded certificate. The data you're trying
to add to userCertificate appears to be base64 encoded ASCII and not binary.
--
Erwann.
--
Erwann.
--
Erwann.