Hello all,
I encountered a problem when importing several client certificate in usercertificate attribute.
The error was :
[15362]: >>> certificateExactNormalize: <0x7f07019a9100, 1745> [15362]: dnX509Normalize: <(null)> (21) [15362]: <<< certificateExactNormalize: <0x7f07019a9100, 1745> => <(err)> [15362]: <= str2entry NULL (ssyn_normalize 21) [15362]: conn=1591 op=17 RESULT tag=103 err=21 text=userCertificate;binary: value #0 normalization failed
Looking through the certificateExactNormalize in sourcecode, it seems the problem comes from the normalization of IssuerDn. Sure enough, in my case the issuer dn is :
CN = Certigna Services CA 2.5.4.97 = NTRFR-48146308100036 OU = 0002 48146308100036 O = DHIMYOTIS C = FR
Openldap has problem with the "2.5.4.97 = NTRFR-48146308100036" part, it is declared as organizationIdentifier but don't appear in openldap core schema (yet ?).
I managed to avoid the error by adding an attribute to schema but I'm wondering if there is not a better way to do it, and why is the normalize called here ?
My ldap version is the debian one : # slapd -V @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $ root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd
Is an update sufficient?
Thank you for your answers, Cédric Couralet
Am Wed, 27 Dec 2017 12:58:13 +0100 schrieb Cédric Couralet cedric.couralet@gmail.com:
Hello all,
I encountered a problem when importing several client certificate in usercertificate attribute.
The error was :
[15362]: >>> certificateExactNormalize: <0x7f07019a9100, 1745> [15362]: dnX509Normalize: <(null)> (21) [15362]: <<< certificateExactNormalize: <0x7f07019a9100, 1745> => <(err)> [15362]: <= str2entry NULL (ssyn_normalize 21) [15362]: conn=1591 op=17 RESULT tag=103 err=21 text=userCertificate;binary: value #0 normalization failed
Looking through the certificateExactNormalize in sourcecode, it seems the problem comes from the normalization of IssuerDn. Sure enough, in my case the issuer dn is :
CN = Certigna Services CA 2.5.4.97 = NTRFR-48146308100036 OU = 0002 48146308100036 O = DHIMYOTIS C = FR
Openldap has problem with the "2.5.4.97 = NTRFR-48146308100036" part, it is declared as organizationIdentifier but don't appear in openldap core schema (yet ?).
I managed to avoid the error by adding an attribute to schema but I'm wondering if there is not a better way to do it, and why is the normalize called here ?
My ldap version is the debian one : # slapd -V @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $ root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd
Is an update sufficient?
Thank you for your answers, Cédric Couralet
The attribute type organizationIdentifier (2.5.4.97) has been introduced in X.520 only in 2012. It has not been made it's way into LDAP yet. It has been introduced into openssl source code only in May 2017. You should create a private schema which includes organizationIdentifer.
-Dieter
openldap-technical@openldap.org