Environment
Products
Novell eDirectory 8.8 for All Platforms
Novell eDirectory 8.7.3 for All Platforms
Situation
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.
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.
Resolution
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.
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).