Troubleshooting LDAPS Connections on On-premise Adobe Connect Server
Note: This article contains images. You may need to refresh the WordPress page in your browser to view them.
When Adobe Connect attempts an LDAPS connection (typically on port 636), it is acting as a client and needs to trust the certificate presented by the LDAP server. It establishes this trust by checking if the LDAP server’s certificate was issued by a CA whose certificate is present in its cacerts truststore.
Corruption, expiration or deletion of cacerts will prevent LDAPS from working with on-premise Adobe Connect servers.
Some of the Adobe Connect on-premise server updaters contain an update to the Tomcat application server. When you upgrade Tomcat, you must restore any configuration files you have edited therein. They will all get overwritten by a Tomcat version update. Not all the Adobe Connect on-premise updaters contain updates to Tomcat. Here is an example from a previous legacy updater (11.4.7) that does:
Changes made when updating Tomcat may be broader than just the cacerts keystore, but the keystore being overwritten is always something that customers running LDAPS need to consider when applying an updater or upgrade.
Re-importing the certs to the keystore is one solution, but it is often easier to copy/paste the working keystore from the server itself. Before running the updater simply backup the cacerts directory and restore it after applying the updater.
\Connect\12.x\jre\lib\security\cacerts
The certificate must be in a format that the Java runtime environment (JRE) can import into the cacerts keystore using the keytool utility.
DER-encoded X.509 format (often with a .cer or .der extension) andBase64-encoded X.509 format (which is the same as PEM format, often with a .pem or .cer extension) are both acceptable, but the Adobe documentation suggests the former. Convert to to DER-encoded as needed if you run into issues.
The certificate imported into the cacerts file must be a certificate that establishes trust for your LDAP server. This is typically the Certificate Authority (CA) Certificate: The Root CA certificate and any Intermediate CA certificates that signed your LDAPS server’s certificate. This is the most common and secure method, as it allows trust for any server certificate issued by that CA. In some cases also the LDAP Server Certificate from the LDAPS server’s specific certificate directly may be imported, but this is less common for the cacerts file which is designed to hold trusted CAs. If your LDAPS server uses a self-signed certificate, you must import that self-signed certificate.
The technote for setting up LDAPS is here: Configure Connect Directory Services to use LDAPS
Overwriting the keystore may also affect other secure functions. See the following technotes for further reference:
Connect on-premise: Event Emails may fail to be sent
Troubleshooting On-premise Telephony SSL Handshake
Configuring Secure SQL with Connect
SSL Configuration Checklist for Connect with AEM-based Events