[Ejbca-develop] LDAP CRL publishing bug

[Mike J. <mj...@sc...>]

Hi,
 I also posted this to the help forum, but I finally decided to 
subscribe to the mailing list so I'm also posting it here.

 Ejbca 2.1 does not send an RFC 2256 compliant CRL to LDAP. The 
certificationAuthority objectclass is defined as auxillary in RFC 2256, 
and later versions of OpenLDAP, with schema checking enabled, enforce 
structural integrity.

 The entry which ejbca attempts to add only contains an auxillary object 
class. It doesn't even contain the "top" objectclass, which all entries 
are required to contain.

 Here is an LDIF export of the CRL which ejbca added, when I disabled 
schema checking on the LDAP server:

dn: cn=ejbca,dc=jackson,dc=net
objectClass: certificationAuthority
cACertificate;binary:
certificateRevocationList;binary:

(authorityRevocationList is probably just missing because it was empty, 
but it is required)


 Here is a proper example of a CRL LDIF:

dn: cn=ejbca,dc=jackson,dc=net
objectClass: top
objectClass: applicationProcess
objectClass: certificationAuthority
cn: ejbca
cACertificate;binary:
certificateRevocationList;binary:
authorityRevocationList;binary:


 The "applicationProcess" objectclass is structural, and is commonly 
used for CRL entries. It's only required attribute is "cn", which is 
also a required attribute by the OpenLDAP server (or you get a naming 
violation and the entry will get rejected). So, applicationProcess kills 
two birds with one stone.

  I just searched through the archives and seen that many people have 
encountered this bug and I did not see that there was any solution to it 
so far (although I didn't check CVS). Some people have even suggested 
modifying OpenLDAP's core.schema. That is not the answer. This is a bug 
in ejbca's CRL publishing and that's where it should be fixed.

  The solution is fix ejbca so that it adds RFC 2256 compliant CRLs 
according to the example that I have provided above. RFC 2256 does not 
mandate which structural objectclass to use for certificationAuthority, 
but applicationProcess seems to be a good one. It's from the same RFC 
and it's also in the core.schema of OpenLDAP.

  This type of structural integrity checking was not implemented and 
enforced by earlier versions of OpenLDAP, even early in the 2.x range 
IIRC, so you probably didn't notice any structural violations when 
developing ejbca with OpenLDAP back then. The latest versions of 
OpenLDAP do enforce structural integrity, so the structurally 
non-compliant entries are refused if schema checking is enabled. And 
schema checking should always be enabled!

BR,
Mike (LDAP Specialist)