| Erwann Abalea <eabalea@gmail.com>
Sent by: openldap-technical-bounces@OpenLDAP.org 02/07/2013 07:14 AM |
|
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