How to check an LDAPS certificate on Active Directory

⌚ About 2 min read

Check the certificate presented by a domain controller, its trust chain, name, and expiration before troubleshooting LDAPS.

Before you start

Work on a copy or a controlled test when the change can affect production. Keep timestamps, screenshots and the previous configuration so the result can be compared.

Step by step

Identify the exact FQDN used by the LDAP client.
Test TLS on port 636 and inspect the presented certificate.
Check SAN/CN, validity period, Server Authentication EKU, and trust chain.
Confirm that the domain controller has the expected certificate in the computer store.
Retest from the client using the same DNS resolution and FQDN.

Validation

Repeat the original test after the change and confirm that the expected service works without creating a new regression. Document the final state.

Technical deep dive

PKI: CAA issuance and LDAPS usage are different controls

Technical checkpoints

CAA specifies which CAs may issue for a domain; it does not replace client-side TLS validation.
For LDAPS, the DC certificate must cover the FQDN in use and include an appropriate Server Authentication EKU.
LDAPS typically uses TCP

LDAPS

Read the certificate actually presented by the domain controller and verify SAN, EKU, dates and chain.

openssl s_client -connect dc01.example.local:636 -servername dc01.example.local -showcerts

Topic-specific pitfalls

Publishing overly restrictive CAA before identifying all issuing CAs can block future renewal.
Having multiple eligible certificates on a DC can cause Schannel to select an unexpected one.

How to validate

The presented LDAPS certificate is the expected one and clients trust it.
Published CAA records explicitly authorize the CAs actually used by the domain.