*Hello.
I have a problem with importing certificate to OPENLDAP. I had exported a Certificate from Active Directory and then tried to import it into userCertificate attribute. The system show me error because i didn't use binary in file ldif. After I had done correction of file "ldif", I received message value #0 normalization failed.
When I change a SYNTAX of userCertificate from 1.3.6.1.4.1.1466.115.121.1.8 to 1.3.6.1.4.1.1466.115.121.1.40 the file was importing well, and LDAP Browser show me data in attribute userCertificate as Certificate. I could also export data from OPENLDAP.
And now question: what difference between 1.3.6.1.4.1.1466.115.121.1.8 and 1.3.6.1.4.1.1466.115.121.1.40, and which of syntax is more correct to use in my case? In case if 1.3.6.1.4.1.1466.115.121.1.8 is more correct how can i understand where i make mistake? I was trying to import Certificate as base64. As example userCertificate;binary:: MIIHcjCCBxygAwIBAgIQQAAAANG9zQ1Jv2ZMAM6FJDANBgkrBgEEAZxWAQIFADCBgjETMBEGCgmSJo... *
*
With regards, * * Aleksey *
Bonjour,
1.3.6.1.4.1.1466.115.121.1.40 stands for "octet string". That is, something binary without any meaning.
1.3.6.1.4.1.1466.115.121.1.8 stands for "X.509 certificate", something with a structure that can (and will) be parsed by OpenLDAP so it can use it with standardized search filters.
You shouldn't change the userCertificate attribute definition, unless you absolutely know and understand the consequences. Since you're asking what are the differences between those 2 OIDs, I guess you don't know and understand the consequences of this change.
If your certificate can't be imported into your OpenLDAP directory, it's due to one of the following reasons:
- this isn't a X.509 certificate
- this is an X.509 certificate but incorrectly encoded (for example encapsulated into a CMS message)
- this is a correctly encoded X.509 certificate but whose content can't be properly parsed by OpenLDAP
Could you post the complete certificate, and not an excerpt of it? *Hello.
I have a problem with importing certificate to OPENLDAP. I had exported a Certificate from Active Directory and then tried to import it into userCertificate attribute. The system show me error because i didn't use binary in file ldif. After I had done correction of file "ldif", I received message value #0 normalization failed.
When I change a SYNTAX of userCertificate from 1.3.6.1.4.1.1466.115.121.1.8 to 1.3.6.1.4.1.1466.115.121.1.40 the file was importing well, and LDAP Browser show me data in attribute userCertificate as Certificate. I could also export data from OPENLDAP.
And now question: what difference between 1.3.6.1.4.1.1466.115.121.1.8 and 1.3.6.1.4.1.1466.115.121.1.40, and which of syntax is more correct to use in my case? In case if 1.3.6.1.4.1.1466.115.121.1.8 is more correct how can i understand where i make mistake? I was trying to import Certificate as base64. As example userCertificate;binary:: MIIHcjCCBxygAwIBAgIQQAAAANG9zQ1Jv2ZMAM6FJDANBgkrBgEEAZxWAQIFADCBgjETMBEGCgmSJo... *
*
With regards, * * Aleksey *
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.
-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 07:14 AM
To Алексей gloomyad@gmail.com cc openldap-technical@openldap.org Subject Re: import Certificate to userCertificate
Bonjour, 1.3.6.1.4.1.1466.115.121.1.40 stands for "octet string". That is, something binary without any meaning. 1.3.6.1.4.1.1466.115.121.1.8 stands for "X.509 certificate", something with a structure that can (and will) be parsed by OpenLDAP so it can use it with standardized search filters. You shouldn't change the userCertificate attribute definition, unless you absolutely know and understand the consequences. Since you're asking what are the differences between those 2 OIDs, I guess you don't know and understand the consequences of this change. If your certificate can't be imported into your OpenLDAP directory, it's due to one of the following reasons: - this isn't a X.509 certificate - this is an X.509 certificate but incorrectly encoded (for example encapsulated into a CMS message) - this is a correctly encoded X.509 certificate but whose content can't be properly parsed by OpenLDAP Could you post the complete certificate, and not an excerpt of it? Hello.
I have a problem with importing certificate to OPENLDAP. I had exported a Certificate from Active Directory and then tried to import it into userCertificate attribute. The system show me error because i didn't use binary in file ldif. After I had done correction of file "ldif", I received message value #0 normalization failed.
When I change a SYNTAX of userCertificate from 1.3.6.1.4.1.1466.115.121.1.8 to 1.3.6.1.4.1.1466.115.121.1.40 the file was importing well, and LDAP Browser show me data in attribute userCertificate as Certificate. I could also export data from OPENLDAP.
And now question: what difference between 1.3.6.1.4.1.1466.115.121.1.8 and 1.3.6.1.4.1.1466.115.121.1.40, and which of syntax is more correct to use in my case? In case if 1.3.6.1.4.1.1466.115.121.1.8 is more correct how can i understand where i make mistake? I was trying to import Certificate as base64. As example userCertificate;binary:: MIIHcjCCBxygAwIBAgIQQAAAANG9zQ1Jv2ZMAM6FJDANBgkrBgEEAZxWAQIFADCBgjETMBEGCgmSJo...
With regards, Aleksey
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.
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
To jckidder@aep.com cc openldap-technical@openldap.org, openldap-technical-bounces@openldap.org, Алексей 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
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.
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 To jckidder@aep.com cc openldap-technical@openldap.org, openldap-technical-bounces@openldap.org, Алексей 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.
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
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
To jckidder@aep.com cc openldap-technical@openldap.org, openldap-technical-bounces@openldap.org, Алексей 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
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.
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.
openldap-technical@openldap.org
-
Erwann Abalea -
jckidder＠aep.com -
Алексей