000038896 - Certificate not verified error when changing Active Directory identity source from LDAP to LDAPS in RSA Authentication Manager 8.4

Document created by RSA Customer Support Employee on Jun 25, 2020
Version 1Show Document
  • View in full screen mode

Article Content

Article Number000038896
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.4
  • The certificate is retrieved correctly when changing the Active Directory identity source connection in the Operations Console from LDAP to LDAPS.
  • The entire certificate chain has been imported.
  • All the certificates have been verified. They are all correct, and none are expired.
  • When testing the connection from RSA Authentication Manager to Active Directory from the Operations Console the connection fails, as shown below:

User-added image

  • A packet capture shows that the test connection failed with a bad certificate error: 

User-added image

In the /opt/rsa/am/server/logs/ImsTrace.log, the following error is found at the time of test connection:

[[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'], (LDAPConnectionTesterImpl.java:231),
ERROR, am84p.vcloud.local,,,,LDAP Server connection test failed
javax.naming.CommunicationException:[Root exception is javax.net.ssl.SSLException: Certificate not verified.]
        at com.sun.jndi.ldap.Connection.<init>(Connection.java:238)
        at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
        at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1609)
        at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
        at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
        at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
        at javax.naming.InitialContext.init(InitialContext.java:244)
        at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
        at com.rsa.ims.common.ldap.GetLDAPConnectionTask.call(GetLDAPConnectionTask.java:70)
        at com.rsa.ims.common.ldap.GetLDAPConnectionTask.call(GetLDAPConnectionTask.java:1)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLException: Certificate not verified.
        at com.rsa.sslj.x.aI.b(Unknown Source)
        at com.rsa.sslj.x.aI.a(Unknown Source)
        at com.rsa.sslj.x.aI.a(Unknown Source)
        at com.rsa.sslj.x.ap.c(Unknown Source)
        at com.rsa.sslj.x.ap.a(Unknown Source)
        at com.rsa.sslj.x.ap.j(Unknown Source)
        at com.rsa.sslj.x.ap.i(Unknown Source)
        at com.rsa.sslj.x.ap.h(Unknown Source)
        at com.rsa.sslj.x.aT.startHandshake(Unknown Source)
        at com.sun.jndi.ldap.Connection.createSocket(Connection.java:393)
        at com.sun.jndi.ldap.Connection.<init>(Connection.java:215)
        ... 18 more
Caused by: com.rsa.sslj.x.aL: Certificate not verified.
        at com.rsa.sslj.x.bh.a(Unknown Source)
        at com.rsa.sslj.x.bh.a(Unknown Source)
        at com.rsa.sslj.x.bh.a(Unknown Source)
        ... 28 more
Caused by: java.security.cert.CertificateException: KeyUsage does not allow digital signatures
        at com.rsa.sslj.x.ck.checkServerTrusted(Unknown Source)
        at com.rsa.sslj.x.aF.a(Unknown Source)
        ... 31 more

Although certificate is valid, it is missing the digital signature field under the key usage extension. This can be confirmed from the packet capture by inspecting the server key exchange packet. In the example below, the digital signature extension is false, confirming that it is missing.

User-added image

The key usage extension can also be confirmed by viewing the certificate directly and checking for the digital signature under Details and then Extensions Only.
ResolutionYou will have to generate a Certificate Signing request (CSR) and set the key usage extension to true. Following is an example of generating a new root certificate and a new server self-signed certificate to use for LDAPS.

To complete these steps, you must have a server with openssl installed and access to the Active Directory server.
  1. Create a new root certificate using the following command on the server with openssl.  

$ openssl genrsa -aes256 -out ca.key 4096
$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

  1. Copy the resulting ca.crt to the Active Directory server. 
  2. Open the Microsoft Management Console by clicking Start > Run > mmc.exe.
  3. Click File > Add/Remove Snap-ins
  4.  In the Add or Remove Snap-ins window, select Certificates, and click Add.
  5. Import the ca.crt from step 1 to the Trusted Root Certification Authorities certificate store.
  6. Create a file named req.inf, which should be like the example below, but with your AD server FQDN listed:

Signature="$Windows NT$"

KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

OID = ; Server Authentication

  1. Open a command prompt on the AD server.
  2. Run the following command to create the private key:

C:\> certreq -new request.inf client.csr

  1. Copy the client.cst to the server with openssl.
  2. Create an extension file named v3ext.txt, like the example below. This ensures that the key usage is set to true.


  1. Run the following command to create the certificate:

openssl x509 -req -days 3650 -in client.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt -set_serial 01 -out client.crt

  1. Copy the certificate back to the Active Directory server.
  2. From a command prompt, run:

certreq -accept client.crt

  1. Verify that the certificate is now present under Personal Certificates in the MMC and has a private key that corresponds to it.
  2. Retrieve the certificate and import to into the Operations console again.