I recently ran into a situation in which I needed and SSL certificate for a DC which did not have access to a Certificate Authority. In order to configure secure LDAP to authenticate against a DC, the domain controller must have a Domain Controller Authentication certificate configured for server authentication. Normally, you would simply set up an Enterprise CA that will happily issue certificates to its domain members. However, what I did have was an Enterprise Certificate Authority in another AD forest, but on another network (separated by a strict firewall) which means my DC could not connect to the certsrv site on the CA.
You would think getting a Domain Controller Authentication Certificate from this disjointed CA would be rather difficult but it is in fact easier than it seems. All the information you really need is Microsoft KB 321051, How to enable LDAP over SSL with a third-party certification authority.
What the MS article doesn’t tell you is that you must modify the Certificate Template in order to get it to work. To boil it down to the essentials, I’ve detailed the process as follows:
1. On the DC requiring an SSL certificate, create a file named “request.inf” and copy the following text into this new file (replacing parameters in bold red with the actual server information):
;—————– request.inf —————–
[Version]
Signature="$Windows NT$
[NewRequest]
Subject = "CN=servername.corp.com" ; replace with the FQDN of the DC
KeySpec = 1
KeyLength = 2048
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication
[RequestAttributes]
CertificateTemplate = DomainControllerAuthentication
SAN="dns=servername.corp.com"
;———————————————–
2. On the DC, run the following command which utilizes the request.inf we just created and spits out a file named request.req
certreq -new request.inf request.req
3. Log on to the CA server running certificate services
4. Copy the request.req file just generated to this CA
5. On the CA, you must modify the certificate template for Domain Controller Authentication certificate. If you don’t, the certificate signing will fail with the following error:
"The DNS name is unavailable and cannot be added to the Subject Alternate
name. 0x8009480f (-214875377) Denied by Policy Module."
6. To resolve this error, follow these steps:
- On your CA, add the Certificate Templates Snap In to the MMC
- Open properties on the Domain Controller Authentication Certificate Template
- Select the Subject Name Tab
- Change the Radio button to Supply in the request
- Click OK to close the template
While modifying the template properties, ensure the Minimum Key size matches the "KeyLength" parameter in the request.inf file. (Change the certificate template back to its defaults after successfully generating the cert.)
7. Restart certificate services on your CA
8. Submit the request.req file to the CA and save the issued certificate as certnew.cer
9. Copy the certnew.cer file to the DC which originally created the request.
10. Accept the new certnew.cer file on the original DC where the request was generated:
certreq -accept certnew.cer
11. Open Certificates for the Local Computer on the DC, right click the newly created/imported certificate and select properties.
12. On the General tab, deselect Client Authentication and Smart Card Logon, leaving only Server Authentication checked. Click Ok.
One last item, don’t forget to export the trusted root certificate for the CA signing these requests and import that trusted root Certificate into any system connecting to the DC over an LDAPS connection. For example, if you set up ISA or TMG for LDAPS to authenticate against the DC to which we just issued a 3rd party certificate, the ISA or TMG server must have the 3rd party issuing CA’s trusted root certificate in its local trusted root or the LDAPS connection will fail.
Paul Beckford is an IT professional based in Denver, Colorado. Over the last dozen years, Paul has worked “hands-on” in an IT Operations role deploying and supporting a multitude of technologies, such as Network Infrastructure, Windows and Linux servers, most Microsoft Back Office & Infrastructure applications, Virtual Computing, Mobile Computing and Information Security.