I Base64-decoded what was provided (after having added 2 '=' padding
chars), the result was binary data. I hexdumped it, and hand analyzed it
(I'm used to).
What I saw was the DER encoding of the beginning of an X.509 certificate.
The annotated hexdump is the following:
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 <[email protected]>
>
> 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
>
>
> *Erwann Abalea <[email protected]>*
> Sent by: [email protected]
>
> 02/07/2013 11:16 AM
> To
> [email protected]
> cc
> [email protected], Алексей <[email protected]>
> Subject
> Re: import Certificate to userCertificate
>
>
>
>
> Unless I'm mistaken, encoding binary data info base64 is the correct way
> to do when using LDIF files.
>
> 2013/2/7 <*[email protected]* <[email protected]>>
>
> 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* <614-716-4970>
>
> *Erwann Abalea <**[email protected]* <[email protected]>*>*
> Sent by: [email protected]
>
> 02/07/2013 10:06 AM
>
> To
> *[email protected]* <[email protected]>
> cc
> *[email protected]* <[email protected]>, *
> [email protected]*<[email protected]>,
> Алексей <*[email protected]* <[email protected]>>
> Subject
> Re: import Certificate to userCertificate
>
>
>
>
>
>
> 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 <*[email protected]* <[email protected]>>
>
> 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.
