Secure LDAP continues to work even if associated certificate object is deleted in eDirectory.

  • 3980051
  • 20-Sep-2006
  • 26-Apr-2012


Novell eDirectory 8.8 for All Platforms
Novell eDirectory 8.7.3 for All Platforms


1. Exported SSL Certificate DNS associated to an 88 or 873 LDAP server object (Trusted Root certificate, no private key, DER format)
2. Used this der from an ldapsearch client to connect to port 636 (or LDAPS port). This worked fine.
3. Delete the Certificate object from step 1 in the tree.
4. LDAP secure continues to load, Reloading eDirectory or LDAP shows no errors. Clients can continue connecting over LDAP secure with the old der file from step 2.


The SSL operations are working as designed. When the Trusted Root Certificate is exported, it is equivalent to exporting the tree's CA certificate. This implies that the certificate is not tied to a single KMO and all certificates signed by the CA are valid for SSL operations against the LDAP server(s).
The only problem is that LDAP secure server continues to load even after the associated certificate object is deleted. The reason for this behavior is that the LDAP server attribute which holds the KMO name is a SYN_CI_STRING and not a SYN_DIST_NAME (DN syntax). Had it been SYN_DIST_NAME, once the KMO object was deleted, the attribute holding this DN would have gone away as well on account of referential integrity. This problem is fixed in Novell eDirectory 8.7.3 Support Pack 9.
As a workaround, you can associate another certificate (existing/new) to the concerned LDAP server.
Note that because we are exporting the Trusted Root Certificate in step 1, clients will be able to use the older der files for SSL operations even after a new certificate is associated to the LDAP server. This statement assumes that the tree CA has not changed.

Additional Information

Note that the PKI server (along with NTLS and NILE) caches the Certificates in the dibdir/certserv/kmocache directory. This was an enhancement which allows secure access to the server even when eDirectory is either not up (NLM timing issue) or damaged. This is working as designed. The correct way to ensure that PKI does not use the certificate is to revoke it. If the certificate is deleted from eDirectory restarting the service caching the certificate should clear it as well. The new 3.x version of PKI provides the capability to revoke a certificate (if the system has been configured for CRL generation).