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 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
*Erwann Abalea eabalea@gmail.com* Sent by: openldap-technical-bounces@OpenLDAP.org
02/07/2013 11:16 AM To jckidder@aep.com cc openldap-technical@openldap.org, Алексей gloomyad@gmail.com 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 <*jckidder@aep.com* 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* <614-716-4970>
*Erwann Abalea <**eabalea@gmail.com* eabalea@gmail.com*>* Sent by: openldap-technical-bounces@OpenLDAP.org
02/07/2013 10:06 AM
To *jckidder@aep.com* jckidder@aep.com cc *openldap-technical@openldap.org* openldap-technical@openldap.org, * openldap-technical-bounces@openldap.org*openldap-technical-bounces@openldap.org, Алексей <*gloomyad@gmail.com* gloomyad@gmail.com> 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 <*jckidder@aep.com* 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.