PAM and LDAPS connection and Certificate


Article ID: 128932


Updated On:


CA Privileged Access Manager - Cloakware Password Authority (PA) PAM SAFENET LUNA HSM CA Privileged Access Manager (PAM)


Customer is configuring LDAP connection to AD via LDAPS connection(TCP Port 636).
Where should the Certificate Chain need to be imported for LDAPS connection?


Component: CAPAMX


PAM trusts all the server certs during LDAPS connections.
When you configured LDAPS for the first time, you might not have imported any certificate chain and successfully established LDAPS due to the above reason.

You do not need to import the Certificate Chain for your LDAP into PAM for successful SSL handshake.

Having Cipher suite mismatch is a different matter.
Especially when PAM is running in FIPS mode, the LDAP Browser may fail to establish connection to LDAPS due to cipher mismatch if certain ciphers are disabled at the LDAP server side.

This is due to LDAP Browser(JXPlorer) not supporting the most current ciphers suite.
If your PAM server was configured in FIPS mode and if the LDAPS was working fine and you can connect using LDAP Browser(JXPlorer) then there is no problem.

If you started to harden the LDAP server by restricting the certain cipher suites then LDAP Browser may encounter cipher mismatch.
In that case customer will need to capture packets between PAM and LDAP server to determine which ciphers need to be allowed to avoid this issue.

Note that PAM 3.3 will be shipping with updated JXPlorer to support newer ciphers including Diffie-Hellman cipher suites that enable Perfect Forward Secrecy (PFS)

It would be good to capture network packets and see what PAM's LDAP Browser is using for Client Hello.

For example, it may be as below.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256   { 0xC0,0x27 }
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA      { 0xC0,0x14 }
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA      { 0xC0,0x13 }
TLS_RSA_WITH_AES_128_GCM_SHA256         { 0x00, 0x9C }
TLS_RSA_WITH_AES_256_CBC_SHA256         { 0x00, 0x3D }
TLS_RSA_WITH_AES_128_CBC_SHA256         { 0x00, 0x3C }
TLS_RSA_WITH_AES_256_CBC_SHA            { 0x00, 0x35 }
TLS_RSA_WITH_AES_128_CBC_SHA            { 0x00, 0x2F }
TLS_DHE_RSA_WITH_AES_128_CBC_SHA        { 0x00, 0x33 }
TLSCipherSuites: TLS_DHE_DSS_WITH_AES_128_CBC_SHA        { 0x00, 0x32 }


You can install 3rd party tools such as "IIS Crypto" to find out what ciphers and hashes are enabled on your AD server.

In this case it is only the SHA256 that is causing the handshake failure.

Additional Information

Setting up LDAPS connection in PAM: