Getting error "com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager$LDAPSSLException: No trusted certificate found" in CAPAM tomcat log
search cancel

Getting error "com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager$LDAPSSLException: No trusted certificate found" in CAPAM tomcat log


Article ID: 262667


Updated On:


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


Sometimes during operation, password change of Active Directory target accounts fails with error similar to the following

2023-03-08T16:25:04.839+0000 INFO [com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager] CSPMTrustManager.checkServerTrusted certificate:
2023-03-08T16:25:04.843+0000 INFO [com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager] CSPMSSLSocketFactory init()
2023-03-08T16:25:04.846+0000 INFO [com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager] CSPMSSLSocketFactory init()
2023-03-08T16:25:04.856+0000 INFO [com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager] CSPMTrustManager.checkServerTrusted certificate:
2023-03-08T16:25:04.860+0000 INFO [com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager] com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager.loginToActiveDirectoryServer Failed authentication to Active Directory using account 'xxxx'
    com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager$LDAPSSLException: No trusted certificate found

And the password rotation does not take place



CA PAM multiple versions


Connecting to Active Directory to perform a password change requires the connection to use SSL which- in turn- requires a certificate to be used.

When the process to log in to AD to perform the password change is started, PAM downloads to its local store the certificate that the domain controller it has contacted is presenting and saves it in its trusted certificates local store. In this way, all subsequent exchanges will occur seamlessly.

In a situation where PAM may be contacting a domain behind which several domain controllers exist, it is possible that the initial contact- and certificate- is done with domain controller A, whereas subsequent operations happen with a different domain controller (let's call it B). In this case, the certificate presented by domain controller B will not be recognized by PAM as trusted, because what it has in its trusted certificates store is the certificate for domain controller A.

As a result this message will be presented and the password change will fail


A possible solution is to make sure that the certificate shared by the different domain controllers for LDAP operations is the same across the domain. If this is is not possible, setting in the target application the IP of a specific domain controller instead of the generic domain (which may cause any domain controller to be contacted on every interaction) may also help.