LDAPS and Certificate Creation

A Certificate Authority (CA) or Enterprise Root CA already installed (you can also use an Intermediate CA).

The Domain Controllers must be domain-joined and reachable.

You must have Domain Admin or Enterprise Admin privileges.

Verify your Certificate Authority setup

If you already have a Root CA and an Intermediate CA:

Keep the Root CA powered off for security — this is normal.

The Intermediate CA (IA) is used to issue certificates to domain controllers.

Make sure both Root and Intermediate CA certificates are trusted on all domain members.

You can check this under:

certmgr.msc → Trusted Root Certification Authorities
certmgr.msc → Intermediate Certification Authorities

If you do not have an Enterprise CA yet:

Add-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
Install-AdcsCertificationAuthority -CAType EnterpriseRootCA

 Create or duplicate a certificate template for Domain Controllers

On the CA (Certification Authority) server, open the Certification Authority console.

Right-click Certificate Templates → Manage.

Find and duplicate one of these templates:

Kerberos Authentication

or Domain Controller Authentication

On the new template:

General tab: give it a clear name (e.g. LDAPS-DC-Certificate).

Extensions tab: make sure Server Authentication (1.3.6.1.5.5.7.3.1) is listed under Application Policies.

Subject Name tab:
Select Build from this Active Directory information → Fully distinguished name must be checked.

Security tab:
Grant Enroll and Autoenroll permissions to:

Domain Controllers

or a specific group (e.g. “Domain Controllers” built-in group)

Close the template and go back to the main CA window.

Right-click Certificate Templates → New → Certificate Template to Issue, then select the new template (LDAPS-DC-Certificate).

Auto-enroll or manually request the certificate on each Domain Controller
Option A – via Group Policy (recommended)

Open Group Policy Management → Edit your Default Domain Controllers Policy.

Go to:

Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies

Enable:

Certificate Services Client – Auto-Enrollment

Configure it as Enabled, Renew expired certificates, and Update certificates that use certificate templates.

Force a GP update on each DC:

gpupdate /force

The certificate should appear automatically under:

certlm.msc → Personal → Certificates

Option B – manual enrollment

If auto-enrollment doesn’t work:

Run certlm.msc on the DC (Certificates – Local Computer).

Go to Personal → Certificates → All Tasks → Request New Certificate → Next → Active Directory Enrollment Policy → Next.

Select your new template (e.g. LDAPS-DC-Certificate).

Click Enroll and verify that the certificate is issued successfully.

Verify the certificate on the Domain Controller

In certlm.msc, open the new certificate and check:

Property    Expected
Intended Purposes    Server Authentication
Issued To    The FQDN of the Domain Controller (e.g. dc01.domain.local)
Issued By    Your Intermediate CA
Valid From/To    Current date range
Private Key    Present (shows “You have a private key corresponding to this certificate”)
Restart services or reboot the DC

After the new certificate is installed:

Restart-Service NTDS
Restart-Service KDC
Restart-Service DNS

Or simply reboot the DC.
This ensures the new certificate is loaded by the Schannel (SSL/TLS) subsystem.

Test LDAPS connection
Method 1 – Using LDP.exe

Run ldp.exe (installed with RSAT or AD DS Tools).

Go to:

Connection → Connect

Enter:

Server: dc01.domain.local

Port: 636

Check SSL

Click OK — if the RootDSE info appears, LDAPS works.

Method 2 – Using PowerShell
Test-NetConnection dc01.domain.local -Port 636

If you see “TcpTestSucceeded : True”, LDAPS is listening and ready.

 Use the same CA to issue certificates for other systems

Once your CA/IA setup works, you can reuse it for other internal systems:

VMware vCenter

Web applications (IIS, monitoring tools, etc.)

File servers (SMB over TLS, HTTPS management consoles)

You just need to:

Create a new Web Server or Custom Web Certificate Template with Server Authentication EKU.

Enroll or auto-enroll each server using that template.

 Summary
Step    Action
1    Verify Root + Intermediate CA trust
2    Duplicate and issue a new certificate template for Domain Controllers
3    Allow auto-enrollment for Domain Controllers
4    Request and verify the new certificate
5    Restart AD DS to apply the certificate
6    Test LDAPS on port 636
7    Reuse CA for other internal web systems

How to convert LDAP to LDAPS (Active Directory)
Prepare certificates
Issue or renew a server certificate for each Domain Controller from your internal CA.
The certificate must be in the Local Computer → Personal → Certificates store.
Ensure trust chain
All clients and servers must trust the issuing CA (root + intermediate certificates).
Restart Domain Controller
After installing the certificate, restart the DC or the Active Directory Domain Services so LDAPS starts listening on port 636.
Test LDAPS
Use the built-in LDP tool (ldp.exe):If it connects and displays the RootDSE information, LDAPS is working.
Connection → Connect → [DC name] → Port 636 → SSL
Update clients
Modify your applications, appliances, and services to use LDAPS (port 636) instead of LDAP (389).
Verify that the FQDN in their configuration matches the certificate subject.

Key Concepts & Requirements

Before diving in, here are what must be true for LDAPS to work on an AD DC:

The domain controller must have a valid server certificate in the Local Machine store (Personal) which has:

Server Authentication (EKU) capability

A subject name (or SAN) matching the FQDN of the DC

Trust in the issuing CA (and chain up through the intermediate to the root)

The DC’s LDAP over SSL port 636 must be open (firewall, etc.).

Schannel (the Windows TLS engine) will pick one certificate from what’s in the store; if there are multiple valid ones, it may not pick the one you expect. 
Microsoft Learn

After replacing or renewing the certificate, you often need to restart the DC (or the domain controller services) to force Schannel to use the new one. 
Microsoft Learn

Also: Microsoft has a “How to enable LDAP over SSL with a third-party CA” article which is a solid baseline. 
Microsoft Learn

🛠 Step-by-Step: Issuing LDAPS Certificates & Enabling LDAPS

Here’s a step-by-step you can follow (or adapt to your CA + IA setup):

Step    What You Do    Notes / Tips
1    Power up / verify CA / IA    If your root CA is usually offline, power it on just to issue or renew server certs. The intermediate CA must be online to issue to DCs.
2    Create or configure a certificate template for DCs    In your CA infrastructure, duplicate a “Domain Controller” or “Kerberos Authentication” template. Ensure the template allows Server Authentication, includes Subject Name = FQDN, and the DCs (or “Domain Controllers” group) have Enroll / Autoenroll permissions.
3    Issue the template in CA    In the Certification Authority console → Certificate Templates → New → Certificate Template to Issue → select your new template.
4    On each Domain Controller, request / enroll the certificate    Use the Certificates MMC (Local Computer) → Request New Certificate → select your template → Enroll. Or use autoenrollment if configured.
5    Ensure certificate chain is trusted    Make sure the domain controller has the CA’s intermediate and root certificates in its Trusted Root / Intermediate stores so the chain is valid.
6    Verify certificate properties    In Certificates MMC, check: EKU includes Server Authentication, subject or SAN includes the correct FQDN, private key exists and is accessible to the DC service accounts.
7    Check port 636 availability    Make sure firewall and network allow inbound TCP 636 to the DC.
8    Test LDAPS binding    Use ldp.exe: Connection → Connect → specify the DC’s name and port 636, check SSL. If you get the RootDSE info, it works. Also, check using tools or applications that will connect via LDAPS.
9    Restart / refresh AD services if needed    If the certificate is replaced or newly installed, restart the DC or the Directory Services (or reboot) so the new cert is used by the LDAP listener.
🧩 Why your expired CA-issued cert might not be from the IA

You asked: “I see a certificate issued by the CA (root), expired, not by the IA — shouldn’t the IA have issued it?”

Yes — ideally, the intermediate CA (IA) should issue server certs, not the root CA. If you see a certificate issued directly by the root CA, it likely means:

The IA was not configured properly or not trusted as an issuing CA.

The domain controllers enrolled before the IA was in place, or autoenrollment used a fallback template from the root CA.

The IA certificate chain or trust isn’t properly propagated, so the DC may have enrolled from root instead.

To fix that:

Confirm the IA is a valid subordinate CA and is trusted by domain controllers.

Make sure your new template is issued by the IA, not root.

Re-enroll domain controllers with the proper certificate.

You mentioned the certificate expired last summer — that will break LDAPS, so renewing or replacing is required.