How To: Confirm the Certificate Bound to an AD LDS SSL Port

Version Affected: All

 

Overview

This article explains how to confirm which certificate is actually bound to an Active Directory Lightweight Directory Services (AD LDS) server's SSL port, when testing AD LDS over SSL. Having a certificate present in the server's Personal certificate store does not necessarily mean that certificate is the one AD LDS is using — AD LDS can be tricky to set up correctly.

Confirm the Certificate Bound to the AD LDS SSL Port

1. Confirm the certificate is imported into the Personal certificate store of the ADAM service account (not just the Computer's own Personal store).

2. Once a certificate with a private key is added and its root is trusted, restart the AD LDS service to bind the certificate.
3. To verify which certificate the AD LDS SSL port is actually presenting, use OpenSSL — either on a Linux system, via Windows Subsystem for Linux on a Windows machine, or a Windows build of OpenSSL. Run:

openssl s_client -connect myadlds.server.dom.ext:636

This returns output similar to the following (edited for length):

CONNECTED(00000003)
depth=0 CN = server.domain.local
verify error:num=20:unable to get local issuer certificate
verify return:1
---
Certificate chain
0 s:CN = server.domain.local
i:DC = local, DC = domain, CN = SERVER-CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF/zCCBOegAwIBAgITeQAAAGomGCp3XmutVwACAAAAajANBgkqhkiG9w0BAQsF
...
-----END CERTIFICATE-----
subject=CN = server.domain.local
issuer=DC = local, DC = domain, CN = SERVER-CA
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Verify return code: 21 (unable to verify the first certificate)
---

4. The subject and issuer lines in the output identify the certificate actually bound to and presented by the AD LDS SSL port, confirming whether it's the certificate you expect.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.