LDAPS and Certificate Creation

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.