Back to blog

How to Install an SSL Certificate on an Active Directory Server

6 min read By Signifium

Guides

Active DirectoryLDAPSSSLcertificateAD CSWindows Server

Domain controllers often need a TLS certificate bound to LDAP (LDAPS, typically port 636) so clients can encrypt directory traffic and validate the server identity. This guide covers UI-oriented ways to obtain and install a certificate on an AD DS server: Active Directory Certificate Services (AD CS)—including autoenrollment and manual request—and using a third-party (public) CA with certreq. Replace hostnames and paths with values that match your environment.

UI Steps (Request / Install a DC Certificate)

Option A — Active Directory Certificate Services (AD CS / Enterprise CA)

Recommended for internal deployments where domain-joined clients already trust your enterprise root.

Approach 1: Autoenrollment (best long-term)

  1. In GPMC, edit a GPO linked to Domain Controllers (or one that applies to your DCs).
  2. Go to: Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto-Enrollment.
  3. Set policy to Enabled, and enable:
    • Renew expired certificates
    • Update certificates that use certificate templates
  4. Ensure your CA publishes an appropriate template. Common choices: Domain Controller Authentication or Kerberos Authentication (per your PKI design).
  5. On the DC, run: gpupdate /force
  6. Run: certutil -pulse
  7. Confirm the certificate appears under: certlm.msc → Personal → Certificates

Approach 2: Manual request (UI)

  1. On the DC, run mmc.
  2. File → Add/Remove Snap-in → Certificates → Computer account → Local computer.
  3. Expand Personal.
  4. Right-click Certificates → All Tasks → Request New Certificate.
  5. Choose a DC / server authentication template that includes Server Authentication (EKU 1.3.6.1.5.5.7.3.1).
  6. Complete enrollment and verify the cert under Personal.

Option B — Third-Party Certificate (Public CA)

Use this when non-domain devices must trust LDAPS without deploying your internal root CA (for example, mobile clients or partners that only trust public roots).

You typically create a CSR, submit it to the CA, then install the issued certificate (and intermediate certificates, if provided).

1) Create a CSR with certreq (INF file)

Create C:\Temp\ldaps.inf (adjust Subject and DNS names for your DC FQDN and short name):

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=dc01.mydomain.com"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
HashAlgorithm = sha256

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=dc01.mydomain.com&"
_continue_ = "dns=dc01&"

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

Generate the CSR:

certreq -new C:\Temp\ldaps.inf C:\Temp\ldaps.req

Submit ldaps.req to your public CA (portal, API, or email). Download the issued certificate and any intermediate CA certificates.

2) Install the issued certificate

certreq -accept C:\Temp\ldaps.cer

If the CA bundle includes intermediates, install them in the Intermediate Certification Authorities store (Local Computer), per your CA’s instructions.

Best Practices

  • Name matching: The certificate’s subject/SAN must match the name clients use to connect (FQDN and short name as needed).
  • Private key: Ensure the cert is in Local Computer → Personal with a valid private key for LDAPS.
  • Chain: Install root and intermediate CAs so clients can build a full chain.
  • Test LDAPS after binding (e.g. ldp.exe to port 636 with SSL, or your directory client’s SSL profile).

Test and troubleshoot LDAPS

Common client issues

  1. Certificate not trusted / connection refused
    Ensure the certificate chain is trusted on the client. For self-signed certs, install that exact certificate (or your enterprise root). For AD CS or a third-party CA, install the issuing CA certificates as needed.

  2. LDAP bind fails (wrong credentials)
    Use UPN (user@domain.com) or DOMAIN\user and the correct password. Confirm the account is not locked or disabled.

  3. Timeout or cannot reach server
    Verify the firewall allows LDAP (389) or LDAPS (636) to the domain controller. From the same network, test with ldp.exe or a short PowerShell LDAP bind test.

Verify LDAPS on the server

1) Confirm the DC is listening on 636 (on the DC):

Get-NetTCPConnection -LocalPort 636 -State Listen

Or:

netstat -an | findstr ":636"

2) Test from a client

Test-NetConnection -ComputerName dc01.mydomain.com -Port 636

(Replace dc01.mydomain.com with the hostname clients use.)

3) UI test with LDP.exe (Windows)

  1. On a client, run ldp.exe.
  2. Connection → Connect — Server: your DC FQDN, Port: 636, enable SSL.
  3. If it connects, the LDAPS handshake is working.

4) OpenSSL (if installed)

openssl s_client -connect dc01.mydomain.com:636 -showcerts

Checklist when LDAPS is not listening on 636

  • Certificate is not in Local Computer → Personal
  • Certificate missing Server Authentication EKU
  • Certificate has no private key
  • Name mismatch (SAN/subject does not match the name clients use)
  • Multiple candidate certificates; AD DS is not selecting the expected one
  • Chain or CRL problems (especially with third-party intermediates)

Quick PowerShell checks on the DC

List certificates in LocalMachine\My:

Get-ChildItem Cert:\LocalMachine\My |
  Select-Object Subject, Thumbprint, NotAfter, EnhancedKeyUsageList

Confirm a private key exists:

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.HasPrivateKey } |
  Select-Object Subject, Thumbprint, HasPrivateKey

ADSignify configuration video

Overview of ADSignify (YouTube):

Watch on YouTube if the embed does not load.

FAQ

Do I need a public cert for LDAPS inside the domain?
Often no. An enterprise CA with autoenrollment is enough when all clients trust your AD PKI. Public certs help when clients cannot install your internal root.

Where does this fit with mobile AD tools?
Apps such as ADSignify connect over LDAP/LDAPS; the device must trust the server certificate (install your root/CA or use a public chain). Use this guide for server enrollment and LDAPS verification; the ADSignify configuration section links here for the full walkthrough and keeps a short PowerShell self-signed option on the product page.

What about self-signed certificates?
Possible for lab use; production usually uses AD CS or a public CA so clients can validate the server without manual trust exceptions. For a PowerShell-only install on the DC (NTDS store + restart), see How to Install a Self-Signed Certificate on a Domain Controller Using PowerShell.

This article is for general guidance. Validate certificate templates and security policies with your PKI and security teams before production deployment.