Certificate Template Request Hash – The Real Story

With a lot of focus on moving from SHA1 to SHA256, one question that I get a lot of is how to get certificates issued with SHA256. The short answer is that a CA signs everything is creates with a single hash signature algorithm. There is no mechanism that enables per-template based signature hash specification. So it is slightly confusing when you review the Cryptography tab for a Version 3 or Version 4 template as below.

So if it’s true that a CA uses a single machine wide signature hash, what is this setting really about? If you look closely, we can get more details. The entry reads “Request hash“, note it doesn’t say REQUESTED hash. So we have our first clue, this setting instructs a client computer enrolling against the template what signature algorithm the client should use to sign the enrollment request (CSR if you will). A standard enrollment request is signed by the enrollee’s private key to ensure the enrollment request integrity is maintained enroute to a CA.

So, we have part of the story, the template Request hash setting has no bearing on an issued certificate. An enrollment request can be signed SHA256 but if the CA is configured to sign everything with SHA1, the end result is a SHA1 signed certificate.

So that might be the end of the story, but during a recent class, a student had a good question. What happens if a request is signed with something other than what is specified on the template? Well, many properties of a template are hard and fast rules, such as if a Cryptographic provider is specified, that provider must be used. The Minimum key size is a minimum size, and if a request comes in with a larger key size, that is acceptable. So we were curious what the logic was with Request hash.

To test the scenario, I made myself a template – Contoso Web Server with the request hash set to SHA1 and added to my lab CA. I then used certlm.msc (available Windows 8+) to create a Custom Enrollment based on the template (Right click Personal/All Tasks/Advanced Operations/Create Custom Request). I chose the Contoso Web Sever template and on the Private Key tab of the Enrollment Properties, I changed the Select Hash Algorithm and changed it to SHA256.

So the template set to SHA1 allowed a request to be submitted with a SHA256 signature. It surprised me only in that the attribute doesn’t state Minimum hash, but the behavior certainly seems to imply that.

Not being one to take things at face value, I then tried the opposite. I set the template to SHA256 and submitted a SHA1 request. What do you think happened with that enrollment request? Accepted? Denied? Oh come on, you must know something is up here!

As you can see in this shot, the certificate request was accepted even though the template is set to SHA256 and the request was signed SHA1.

So what causes this behavior? I reached out to my “sources” and found that this setting is NOT enforced. It provides the administrator the ability to set the preferred signature for clients to use during enrollments. When a machine reads the template, it will use the requested hash for its enrollment unless otherwise instructed. In my tests, I simply told the client to use another hash signature. The CA does NOT enforce or check the type of signature hash that was used. However, it will certainly make sure the hash is valid and if its a supported hash no errors are reported. But it will not deny the enrollment because the signature hash is stronger or weaker than the one specified in the template.

So not only do you now know that the Request hash setting in the template has no impact on the final issued certificate, it is also not an enforced setting for incoming enrollment requests.