Please try to ensure that the following recommendations are met. For ease of reference, the Encryption Management Server that is making the LDAPS connection is referred to below as the LDAPS client and the remote Encryption Management Server that is hosting the LDAPS service is referred to as the LDAPS server:
- A valid TLS certificate, preferably issued by a public certification authority, is associated with the relevant network interface of both the LDAPS client and the LDAPS server.
- The certificates in the issuing chain of both the LDAPS server and the LDAPS client are imported into Keys / Trusted Keys in the administration console and trusted for TLS on both the LDAPS server and the LDAPS client.
- The issuing certificate (invariably an intermediate certificate) on both the LDAPS client and LDAPS server contains an Enhanced Key Usage field with the attributes Server Authentication and Client Authentication. This is always the case for certificates issued by a public certification authority but may not be true for private certification authorities.
- The LDAPS client uses DNS name to connect to the LDAPS server. For example, keyserver.example.com.
- The DNS name matches the CN attribute of the Subject field of the LDAPS server certificate.
- Both the LDAPS client and LDAPS server are using Encryption Management Server release 3.4.2 MP3 or above.
If you cannot satisfy the above recommendations, a workaround is to use self-signed certificates on either or both the LDAPS client and LDAPS server. While not best practice, this will bypass the strict SSL checking used by Encryption Management Server.
Thanks for your feedback. Let us know if you have additional comments below. (requires login)