So here’s a question I want you to try answering off the top of your head – Which certificate is your domain controller using for Kerberos & LDAPS and what happens when there are multiple certificates in the crypto store?
The answer is actually pretty obvious if you already know the answer, however this was the question I faced recently, and ended up having to do a little bit of poking around to answer the question.
The scenario in question for me is having built a new multi-tier PKI in our environment I have reached the point of migrating services to it, including the auto-enrolling certificates templates used on Domain Controllers.
For most contemporary active directory installs where AD certificate services is also used, there are two main certificate templates related to domain controllers:
- Kerberos Authentication
- Directory Email Replication
The “Kerberos Authentication” certificate template made it’s appearance in Windows Server 2008, replacing the “Domain Controller” and “Domain Controller Authentication” templates in earlier versions of ADCS. The “Directory Email Replication” template is used where you use email protocols to replicate AD (I am not quite sure why anyone would want to do this in this day & age).
Getting back to my scenario and question, how do you work out which certificate is in use?
In both examples, we’re interested in the certificate serial number. The first way is to use a network analyser such as Wireshark (or MS Message Analyzer) to trace a connection to port 636 of a domain controller:
Using a network analyser is nifty in that you can see the full handshake occurring and the data passed – something crypto-geeks can get excited about 🙂 expanding out the information we can obtain the serial number: 655dc58900010000e01e
Alternatively, if you have openSSL available, you can use the following commands to connect and obtain similar information:
openssl s_client -connect <LDAPS Server>
This will connect to the server and amongst the output will be the offered certificate in bas64 format. Copying the All text between and including —–BEGIN CERTIFICATE—– & —–END CERTIFICATE—– to a file which will give you the public key being offered. You can then run this command:
openssl x509 -in <certificate-file> -check
To obtain all the detailed information on the certificate, including the serial number.
From here, it’s just a matter of checking the personal certificate store on the local computer account and find the certificate with the matching serial:
What Happens for multiple Kerberos Certificates?
Again, looking back at my scenario, I now have two Kerberos Authentication certificates in my store – one from the old CA Infrastructure, and the other from the New CAS Infrastructure, with a different template name to meet naming standards.
Using the tried and true method of “test it and see what happens”, I found that the AD DS service will always use the newest certificate available. That is, the one that has the newest validity start date. As an example, if today is February 26, the certificate which is valid from February 25th will be used over the certificate valid from February 20th.
Changing between certificates is a seamless affair. AD Domain Services doesn’t need restarting, nor does the machine in general.
So there you have it, Domain Controllers at their base use 1-2 certificate templates, based on how you replicate. There’s no native way (that I found) to work out which certificate is being used, so tools like Wireshark and OpenSSL can be useful for obtaining certificate information to reference. Finally, Domain Controllers will use the Kerberos Certificate with the latest validity period.