Reviewing SSL/TLS Certificate Chain for Active Directory Server

Sometimes when I am setting up, or helping someone setup, identity synchronisation between the SAS® platform and Microsoft Active Directory (AD), I run into SSL/TLS certificate validation issues. I am usually using Metacoda Identity Sync, but it can also happen when doing a sync with custom Base SAS code. Often the underlying cause is that the AD server’s CA certificate is not in the SAS Private JRE Trusted CA Bundle (see Did I add that CA Certificate to the SAS Trusted CA Bundle?). When troubleshooting this, one of the first things I will do is look at the certificate that the AD server is providing, and I mostly use an OpenSSL s_client command for this. There are 4 command variations I use depending on whether I am trying to use the main directory or the global catalog, and with LDAP plus STARTTLS, or just LDAPS.

For connecting to the main directory on the unencrypted LDAP port 389 with an upgrade to encrypted using STARTTLS:

echo "Q" | openssl s_client -connect -starttls ldap -showcerts

For connecting to the main directory on the encrypted LDAPS port 636:

echo "Q" | openssl s_client -connect -showcerts

For connecting to the global catalog on the unencrypted port 3268 with an upgrade to encrypted using STARTTLS:

echo "Q" | openssl s_client -connect -starttls ldap -showcerts

For connecting to the global catalog on the encrypted port 3269:

echo "Q" | openssl s_client -connect -showcerts

If you want to examine the returned certificate in more detail then you can also pipe it to an OpenSSL x509 command e.g.

echo "Q" | openssl s_client -connect -starttls ldap -showcerts | openssl x509 -noout -text

If you have questions, or any other tips for troubleshooting SSL/TLS certificates with AD, then please leave a comment below.

2 thoughts on “Reviewing SSL/TLS Certificate Chain for Active Directory Server”

  1. Hello Paul,
    Thanks for this interesting paper.
    I have to connect to my AD Server on the encrypted LDAPS port 636 in a SAS Base batch running on my SAS Windows Server (no workspace) to synchonize identities with the SAS Meta server (i use customized SAS program :
    First, I add my AD certificat on the Windows CA Store in my SAS Server. The following command is KO :
    openssl s_client -port 636 -host myADServer
    Secondly, I add my AD certificat to the SAS Trusted Bundle and test the following command which is OK :
    openssl s_client -port 636 -host myADServer -CAfile \SASSecurityCertificateFramework\1.1\cacerts\trustedcerts.pem

    Testing my SAS program in a workspace : OK
    Testing my SAS program in a simple SAS base session on SAS server : KO
    ERROR: LDAP SSL Message ldapsNegotiate() failed -2139099111.
    ERROR: Possible cause: Server certificate not found, port not SSL enabled

    It seems my AD server certificat is not find when using SAS Base session. I can not use SSLCALISTLOC option because Windows and not Unix …

    Did you already meet this problem or behavior ?
    Thanks a lot !

  2. Hi Oliver,

    Thanks for the feedback and question. I use our Metacoda Identity Sync plug-in for synchronizing identities these days so most of my recent experience is with configuring Java processes for LDAPS rather than Base SAS processes. I don’t have SAS on Windows to test it myself but from reading the documentation it seems that it uses the Windows Certificate Store –

    I see from your comment that you have added your CA certificate (root and any intermediates?) to the Windows CA store but you didn’t mentioned whether it was the machine store (for all users) or a personal store (for a single user). The fact that it worked for you in a workspace session but not an interactive session makes me wonder whether you added it to a personal store and the 2 SAS sessions were running under different identities (or on different machines). Have you tried adding the CA certs to the machine store instead? Also, is your SAS Workspace Server load balanced so therer may be the possibility the store on one machine was updated but another was not?

    I hope this helps you find the cause of the issue.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.