LDAPS on a domain controller

Verified 2026-09-24 against a real domain controller with an internal enterprise root CA, from a Rocky Linux appliance running the centre.

Active Directory sign-in checks an operator's password against a domain controller. That password must not cross the network in the clear, so Ballast only talks to a domain controller over an encrypted connection, and plain LDAP is refused. There are two ways to get an encrypted connection:

• LDAPS (ldaps://, port 636): TLS from the first byte. This is what this page sets up, and what Ballast recommends.
• StartTLS (ldap://, port 389, with the StartTLS option ticked): the same certificate requirements, over the plain LDAP port. Everything on this page applies to it too.

Either way the domain controller needs a certificate, and the Ballast centre needs to trust the CA that issued it. Windows domain controllers do not have a usable LDAPS certificate until somebody gives them one, which is why this is usually the first thing to do.

1. Check whether it already works

Run this on the centre (or any Linux box with openssl), using the domain controller's DNS name:

openssl s_client -connect hypervdc.ballast.local:636 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

What you see	What it means
Subject, issuer, dates and a DNS: entry naming the domain controller	LDAPS is on. Go to step 4.
connect: Connection refused, or no output at all	Nothing is listening on 636. The domain controller has no suitable certificate yet, or a firewall is in the way. Continue with step 2.
An error such as no peer certificate available	The same: no certificate is installed. Continue with step 2.

Check the output while you are here. The certificate must list the domain controller's own DNS name (the DNS: entry) and that is the name you must use in the Server URL. It is not valid for its IP address.

From a Windows machine, Test-NetConnection hypervdc.ballast.local -Port 636 answers the "is anything listening" question. ldp.exe (Connection, Connect, port 636, SSL ticked) answers the whole thing.

2. What the domain controller's certificate needs

A domain controller starts offering LDAPS by itself, with no service restart, when a certificate that meets all of these is in its Local Computer, Personal certificate store:

• It has a private key, held on the domain controller.
• Its Enhanced Key Usage includes Server Authentication (1.3.6.1.5.5.7.3.1).
• It names the domain controller's fully qualified DNS name, in the Subject Alternative Name (or as the subject's common name).
• It is within its validity dates.
• It was issued by a CA that the domain controller itself trusts.

The certificate templates that ship with Active Directory Certificate Services, Domain Controller, Domain Controller Authentication and Kerberos Authentication, all meet this. You do not need a special "LDAPS" template.

3. Get a certificate onto the domain controller

Pick the situation that matches yours.

You already have a CA (Active Directory Certificate Services)

An enterprise CA normally hands domain controllers a certificate by itself through auto-enrolment. If port 636 is not answering yet, ask the domain controller to enrol now. On the domain controller, in an elevated PowerShell:

gpupdate /force
certutil -pulse

Then look for the certificate:

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains 'Server Authentication' } |
  Select-Object Subject, NotAfter, Issuer

If nothing turns up, request one directly:

Get-Certificate -Template DomainControllerAuthentication -CertStoreLocation Cert:\LocalMachine\My

This works only if the CA publishes that template and the domain controller computer account is allowed to enrol for it (the default for domain controllers). If it fails, check the template is enabled on the CA, or request one from the Certificates console: Local Computer, Personal, Request New Certificate.

You have no CA at all

Install one. For a lab or a small environment, an enterprise root CA on a domain controller is the quick way, and it makes every domain controller enrol automatically afterwards. Run this on the domain controller, as a member of Enterprise Admins:

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Install-AdcsCertificationAuthority -CAType EnterpriseRootCa `
  -CACommonName "Ballast Root CA" `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -KeyLength 4096 -HashAlgorithmName SHA256 `
  -ValidityPeriod Years -ValidityPeriodUnits 10 -Force

Then run the enrolment commands from the section above so the domain controller picks up its certificate.

For production, do not run your only CA on a domain controller. Microsoft's guidance is a dedicated, offline root with an issuing CA beneath it. That is beyond this page. What matters to Ballast is the same in every design: it needs the certificate of the CA that issued the domain controller's certificate.

You use a certificate from another CA

Request a certificate that meets the list in step 2, import it into the domain controller's Local Computer, Personal store, and make sure the domain controller trusts the issuing CA. The rest of this page is the same.

If port 636 still does not answer

A domain controller normally picks up a new certificate on its own within a few minutes. To make it look now without restarting anything, use ldp.exe on the domain controller: Connection, Connect, then Browse, Modify. Leave Dn empty, set Attribute to renewServerCertificate, Values to 1, Operation to Add, tick Extended, then Enter and Run. As a last resort, restarting the domain controller does it too.

Then run the check in step 1 again.

4. Give the centre the CA's certificate

The centre has to trust the CA that signed the domain controller's certificate. If it does not, the Test in Ballast says so in plain words: the directory server's certificate is signed by an authority the centre does not trust.

Find the issuer from step 1. The issuer= line names it, for example CN=Ballast Root CA. Then export that CA's certificate as text. On the CA, or any domain-joined Windows machine, in PowerShell:

$c = Get-ChildItem Cert:\LocalMachine\Root |
  Where-Object Subject -like '*Ballast Root CA*' |
  Select-Object -First 1
$c | Select-Object Subject, NotAfter, Thumbprint

"-----BEGIN CERTIFICATE-----`n" +
  [Convert]::ToBase64String($c.RawData, 'InsertLineBreaks') +
  "`n-----END CERTIFICATE-----" | Set-Clipboard

Two details matter here:

• Select-Object -First 1 is not optional. A store can hold more than one entry with the same name. Without it you get two certificates joined into one block, which is not a valid certificate, and Ballast rejects it as "not valid PEM".
• The result must start with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.

If the CA certificate is not in that store, export it from the CA server itself instead:

certutil -ca.cert C:\root-ca.cer
certutil -encode C:\root-ca.cer C:\root-ca.pem

and open the .pem file in a text editor.

Paste the text into Settings, Authentication, Active Directory, Advanced: certificate authority and user filter, CA certificate (PEM). If your CA has an intermediate as well as a root, paste both, one after the other. Then use Test connection.

Keeping it working

• Certificates expire. With auto-enrolment, a domain controller renews its certificate itself, and because the CA that issued it is unchanged the centre keeps trusting it. If the domain controller's certificate is ever replaced by one from a different CA, paste that CA's certificate too, or directory sign-in will start failing. It fails safe: open sessions carry on, new directory sign-ins are refused, and local accounts still work.
• One domain controller per Server URL. Ballast connects to the single domain controller you name, and its certificate must name that host. There is no automatic failover to another domain controller.
• The CA's own certificate lasts as long as you chose when you built it (ten years in the example above). Put its expiry in your calendar.

Problems

You see in Ballast	Cause	Fix
The certificate is signed by an authority the centre does not trust	The CA certificate is missing from the CA certificate field.	Step 4.
The CA certificate is not valid PEM	The pasted text has two certificates in one block, or is missing a BEGIN/END line.	Re-export with Select-Object -First 1.
The certificate does not name the host in the URL	The Server URL uses an IP address or an alias the certificate does not list.	Use the DNS name shown by the DNS: entry in step 1.
The certificate is expired or not yet valid	The domain controller's certificate is out of date, or the centre's clock is wrong.	Renew the certificate. Check the centre's time.
Could not reach the directory	Port 636 is closed or nothing is listening.	Steps 1 to 3, and check firewalls between the centre and the domain controller.
The name does not resolve from the centre	DNS on the centre cannot find the domain controller.	Fix DNS on the centre.