Hi there!

I hope someone can help me with this issue!

I’m trying to get IS working with an Active Directory using an LDAP over SSL (LDAPS) connection. I have set up the AD server to also act as a CA and so have the SSL certificate and the CA certificate exported.

We’re running WM9.8 on a RHEL server.

So far I have imported these certificates into the webMethods jvm cacerts file and into sagdemoca.jks file using the keytool and updated all the relevant settings in MyWebmethods. I’ve also added both certificates into My webMethods and the IS web interface (on port 5555).

User authentication is working fine.

However we have a webapp which calls into the IS to get a list of users which can be imported from AD. Ultimately the IS uses pub.client.ldap:search (EDIT) to get this list.

The call fails and the following error is logged in the server.log file:

08-10@13:24:30 ERROR - LdapSync scLdapSync.services:syncLdapServList [005] LdapSync Core svc: javax.naming.CommunicationException: myadserver:636 [Root exception is iaik.security.ssl.SSLException: Server certificate rejected by ChainVerifier] {fields: }

As far as I can tell all the required certificates are valid and installed where they should be, can anyone tell me what I’m missing?

Many thanks!

Richard.

Hi Richard,

can you provide some more details about the directory service configuration in MWS as well as the Central Users Management config in IS.

sagdemoca.jks is only visible to MWS locally by default.

From the error message I assume that the IS not aware of the CA on which the server certificate of the directoy service is based.

Regards,
Holger

Hi Holger,

Sure! I hope I’ve included everything you asked for?

On the MWM server:
Under My webMethods > System Settings > Directory Services:

Service Enabled: Yes
Connection Error Threshold: 10
Provider URL: ldaps://myadserver:636
Base DN: ou=test,ou=test.dev,ou=migration,dc=test,dc=dev
Groups DN:
User DN:
Security Principal: cn=admin,cn=Users,dc=test,dc=dev
Security Credentials: ****
Failover URLs:
Search Timeout: 0
Enable Default Wildcard Searches: Yes. Enable default wildcard searches
Enable Group Across Directory Service: No. Group Across Directory Service
Enable GroupQuickSearch: Disabled
Active Directory Domain URLs:

Note that if I change the Provider URL to ldap://myadserver:389 everything works as expected.

On the IS server:

Central User Management Configuration (it doesn’t say a lot here)

General
Central User Management	Configured

Under LDAP configuration it just says:

LDAP Configuration
Provider: Central User Management

There are some users but they were created/imported before we switched to ldap over SSL.

Under Security > Certificates > Configure Client Certificates I have:

Current Certificates
Subject         CN Issuer        CN Serial Number                              User            Usage 
myadserver      myadserver-ca    624420865573520599518337896801616688085729282 Administrator   SSL Authentication 
myadserver-ca   myadserver-ca    126470829865116639495240352739903059457       Administrator   SSL Authentication

Hi

I believe the CA certs authentication should be configured and handled at MWS level only and shouldn’t be linked with IS for this scenario.

If Central User Management configured in IS is correct then it should automatically connect to MWS and MWS will be using the details configured inside LDAP connection to authenticate the user by querying the LDAP configured inside My webMethods > System Settings > Directory Services

Regards,
Firoz N

That makes sense, thought I didn’t think it would hurt to have them registered with IS. I tried removing them but I’m still getting the same error as in the OP.

Isn’t it strange that MWS is able to authenticate AD users but scLdapSync.services:syncLdapServList is unable to verify the certificate chain?

Just to sanity check I installed the CA certificate on a Windows machine. I installed Apache Directory Studio, registered the certificate in preferences and copy & pasted the settings from MWS Directory Services. It connected without any problem.

It’s actual the call to pub.client.ldap:search which appears to be throwing the error - updating the OP accordingly.

When IS is connected to the MWS for Central User Management, there is a setting somewhere in Settings Section.
Previously this a database pool/function under Settings- >JDBC Pools, but this should be a JMS Link to UM now.
Database proivder for this function is deprecated since 9.12.
For Central Users Management the IS inherits the directory Service information from MWS via the configured SAML Resolver URL.

Is there a truststore configured in IS under Security->Keystores?
If yes, check if it contains at least the intermediate CA (and corresponding Root if neccessary) of the server certificate of the LDAP server.
The pub.ldap:search initiates its own direct LDAP connection and is not using the directory service inherited from the MWS.
Therefore it will validate the server certificate of the ldaps server itself against its own truststore.
When no truststore is configured the IS will be defaulting back to the base cacerts file from the JVM.

Regards,
Holger

When using LDAPS you must add the SSL cert and chains for the LDAP server into the JDK “cacerts” level.
See also Empower for KB 1773833 - Integration Server truststore not working for external LDAPS service.
This is because the LDAPS connection is done by the JDK, not by the integration server itself.

Hi Holm,

this seems to be dependent whether there is a Truststore configured under Security->Certificates or not.
We have a global Truststore configured there for our HTTPS-Ports containing all the CAs, which are not part of the cacerts file and we did not have to import any server side certificates from the external servers since then (neither LDAPS nor WS hosting servers). Only certs we have explicitly configured are our own server certificate into its own Keystore and the Client certificates of our Partners used for Certificate based authentication instead of User/Password based Basic Auth.

Regards,
Holger

It looks like that was the issue.

As the LDAP server is also acting as CA there should be only 2 certificates in the chain - SSL and CA.

I had previously imported the CA cert and the SSL cert into /opt/webMethods/jvm/jvm/jre/lib/security/cacerts. When attempting to add the CA certificate into the DEFAULT_IS_TRUSTSTORE (/opt/webMethods98/common/conf/platform_truststore.jks) I got the message Certificate already exists in system-wide CA keystore under alias <myadserver-ca> so I assumed it was picking them up from cacerts.

I’ve just added the SSL cert into /opt/webMethods98/common/conf/platform_truststore.jks and now it’s working!

Thank you to everyone for your help on this! I have a much better understanding of how it all fits together now.

Regards,

Richard.

Yes and no.
You can for sure configure your JVM runtime to use another trust store than the default cacerts file.
But when you do this for your IS make sure you also did the same for MWS also, otherwise you can have LDAPS access problems there. That’s why the usual recommendation is to add the keychain for the LDAPS server into the certs file.
That in this case the LDAPS server is identical to the CA server makes this a bit more complex but looks like it works now as expected.

Hi Holm,

sure we have the same truststore configured in MWS too, for providing the HTTPS-Port.
We have build the truststore jks file with “-trustcacerts” so it will use and trust the cacerts file by default.
Therefore we only configure the root and intermediate CA certificates into our truststore file, but we did not have the need to configure any other server certificates except our own ones. Our LDAPS Service is using the same chain as we do for our certificates.

In 9.5 we have the issue that IS cannot connect to the LDAPS service (but MWS can), as it does not support TLS v1.2 for LDAPS connectivity, but only TLS v1.0. This will be solved when we finish our migration to wM 9.12.

Regards,
Holger