|
From: Mike J. <mj...@sc...> - 2004-01-05 21:52:34
|
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) |