Recently, while working on a Microsoft Network Device Enrollment Services (NDES) deployment, a client asked a simple-enough question about the thumbprint for the Certificate Authority (CA) certificate that was displayed on the NDES admin enrollment GUI, “What is that hash? And why doesn’t it match any of the CA certificate thumbprint hashes in my chain-of-authority?”
As part of a broad troubleshooting step for a device that was not enrolling correctly, the client was verifying the setup of the NDES server, and it caused him concern that the thumbprint didn’t match the displayed thumbprints of any CA certificate in his chain.
An overview of NDES
The Network Device Enrollment Service (NDES) is the Microsoft implementation of the Simple Certificate Enrollment Protocol (SCEP), a communication protocol that makes it possible for software running on network devices such as routers and switches, which cannot otherwise be authenticated on the network, to enroll for X.509 certificates from a certification authority (CA).
NDES operates as an Internet Server Application Programming Interface (ISAPI) filter on Internet Information Services (IIS) that generates and provides one-time enrollment passwords to administrators, receives and processes SCEP enrollment requests on behalf of software running on network devices, and retrieves pending requests from the CA. https://technet.microsoft.com/en-us/library/cc753784(v=ws.10).aspx
What is that hash, anyway?
After some verification, including a quick check of the registry keys at HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP, we determined that the NDES server was configured correctly, and pointing to the correct CA.
So I engaged our expert on all things cryptography (Ted Shorter, CSS’ CTO), and we began by taking a look at the public certificate of the issuing CA that the NDES server was pointing to. We could see that its hash didn’t match what we were seeing on the NDES admin page.
And another thing was immediately apparent: the hash in the certificate that we could see through the default Microsoft GUI was 20 bytes (SHA-1), and the hash on the NDES admin page was only 16 bytes. Could the hash on the NDES admin page be the MD5 hash of the issuing certificate?
The Microsoft Checksum Integrity Verifier (FCIV)
We could have pasted together some quick code to check the different hash algorithm values of the issuing CA certificate, but there is a slick tool from Microsoft that would allow us to quickly check an MD5 or SHA-1 hash: The Microsoft Checksum Integrity Verifier (FCIV) https://support.microsoft.com/kb/841290. Used to compare file values against a known good value, it is used to make sure that the files have not been changed.
But it would also work for our purpose. So we ran FCIV against our issuing CA certificate using the FCIV default hashtype of md5.
Nope, that wasn’t it.
What about the root?
Bingo!
The hash that you are presented in the NDES administration page is the MD5 hash of the Root CA certificate!
Why the MD5 hash? That might be a good question for another blog.
