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.