The configuration of Administrative Authentication with SSL enabled user directory fails with error java.security.cert.CertificateException: No name matching ldap-vip.....com found
search cancel

The configuration of Administrative Authentication with SSL enabled user directory fails with error java.security.cert.CertificateException: No name matching ldap-vip.....com found

book

Article ID: 241525

calendar_today

Updated On:

Products

SITEMINDER CA Single Sign On Federation (SiteMinder) CA Single Sign On Secure Proxy Server (SiteMinder)

Issue/Introduction

The configuration of Administrative Authentication with SSL enabled user directory fails with the following error in admin ui:

or sometimes a slightly different error

However, the rootCA cert is loaded in trustStore.jks and server.log show a different error message.

2022-05-06 17:06:14,887

[ERROR] com.ca.siteminder.webadmin.configuration.Configuration [] - java.security.cert.CertificateException: No name matching ldap-vip.......com found

In this environment, the ldap-vip.xxxx.com is the Load balancer name in F5. It is GTM entry that does not have certificate itself.

Behind the F5, there are several ldap servers as the members of the load balancer, the certificate name used are ldap1.....com,ldap2......com,ldap3.....com.

By design, the certificate name won't match with F5 vip hostname.

Environment

Release : 12.8.05

Component : SITEMINDER WAM UI

Cause

From Release 12.8.06, the new parameter named EnableSSLHostnameVerification

in the SSLCipherConfig.properties file can be used to validate the hostname in an SSL request during the federated backchannel communication. If the parameter is set to

true, SiteMinder verifies whether the hostname matches the CN of the server certificate during the SSL handshake.
 
However, in this case, setting EnableSSLHostnameVerification=true has no effect and did not resolve the issue. Perhaps this is for federation use only, not for admin ui.

The true cause is that security measures are enforced since SiteMinder UI version 12.8.02 and above.

Out of box, during ssl handshake, the hostname and ldap endpoint are always verified unless instructed otherwise.

Resolution

In order to disable the hostname and ldap endpoint verification, one can pass "-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true" via JAVA_OPTS parameter during admin ui start up.

Windows: administrationUI_installation_home/bin/standalone.conf.bat file
UNIX: administrationUI_installation_home/bin/standalone.conf file

Windows:
set "JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.keyStorePassword=changeit"
set "JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.trustStorePassword=changeit"
set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true"

UNIX:
JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStorePassword=changeit"
JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStorePassword=changeit"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true"

If you do not use the default standalone.conf file or the default trustStore, you still need a way to pass the disableEndpointIdentification parameter during command line to be effective.

This resolved the error in the end.

Additional Information

https://knowledge.broadcom.com/external/article?articleId=186534

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/single-sign-on/12-8-03/release-notes/known-issues/known-issues-for-policy-server.html

https://knowledge.broadcom.com/external/article/136378/the-root-ca-for-our-company-active-direc.html

https://knowledge.broadcom.com/external/article/57273/the-root-ca-for-our-company-active-direc.html

Attachments