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?
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
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.
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.
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.
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.
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.
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.
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.