Re: [Ejbca-develop] Wrong DN in ldap publisher when using equas sign in entity name

[Michael S. <mi...@st...>]

Michael Postmann wrote:
> I've attached lddiff's of one of our old LDAP entry and one of our new LDAP entries, created by EJBCA.
> 
> My problem is, that the new.ldiff has two "cn" fields of which one is cut
> off and the other one has the equals sign escaped with a backslash.
> And the cut off version is then used for the Subject dn.

Yes, this indeed seems to be broken.

Excerpt from your new LDIF file:

dn: cn=CMS_9999000451_001_test_blah_MAIL,ou=paysafecard[..]
[..]
cn: CMS_9999000451_001_test_blah_MAIL\=ca...@pa...
cn: CMS_9999000451_001_test_blah_MAIL
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

If your input value was CMS_9999000451_001_test_blah_MAIL\=ca...@pa...
then attribute value in 'cn' must not be escaped! And of course the second
truncated attribute value must not be there. Only the DN should contain the
single DN-escaped 'cn' value.

I've looked inside the cert of your new entry.

Don't turn LDAP DN order in EJBCA. It's broken and does exactly the opposite
of what it sounds like (see mailing list archive). You can see it when
displaying the cert with openssl x509 -nameopt rfc2253

The CN attribute in the cert's subject DN seems to be correct since it is
CMS...@pa...

My recommendation:
Don't use the built-in LDAP publisher if you have more specific requirements,
especially regarding naming. You could use the generic publisher for invoking
a script and let a custom script implemented in your favourite scripting
language correctly extract the data from certs and CRL and push it to the LDAP
server. Not sure how robust the error handling is with shell scripts.
Therefore I'd only move the files into a external queue directory and let the
custom publisher read from there.

@EJBCA developers:
Your LDAP publisher is not worse than those of all the other PKI products I've
used. But the handling of DN string representations needs serious overhaul in
various places (as already discussed here).

Ciao, Michael.