In short, Microsoft will discontinue SHA1 signatures in SSL and code signing certificates by January 1 2017. This article raised a lot of questions in TechNet forums and these questions shows policy misunderstanding by users. In this article I want to focus on key moments of the policy, common myths and the second part will show the general guidance for moving toward SHA2.
This policy affects *only* to certificates issued by CA who are members of Windows Root Certificate Program. This means that certificates issued by other CAs (including, enterprise private CAs) still will be able to issue SHA1-signed certificates after that date and they will work as usually.
However, most modern applications do support SHA2 algorithm family, so it is *recommended* to move your CA to sign certificates with SHA2 signature algorithm family (SHA256, SHA384, SHA521). But still not a requirement.
As I pointed several times in previous posts, after 7 years (since Windows Vista was released), CNG algorithm suite (ECC cryptography) is not yet widely supported. Moreover, new mainstream product lines still doesn’t support CNG. For example, cloud infrastructure: System Center, Windows Azure don’t support CNG. This is because all these products rely on .NET and .NET has awful CNG support. But there are workarounds and they are not so complex. Good developers always get over this in develop good products with mainstream technology support.
But the problem with SHA2 is: users think, that their certificates (SSL, code signing, client authentication) must use CNG certificates in order to get SHA2 signature. This is wrong assumption.
That is, only CA server must use provider that is capable to produce SHA2 signatures. Clients may use legacy providers for public keys and have SHA2 signature. Yes, because signature is generated by a issuing CA.
If you are using Windows Server 2008 (or newer) based CA, you can move entire PKI to use SHA2 without reinstalling CAs. The next section will describe the process.
Before I provide exact steps to do this, I’ll talk about key points you need to understand prior modifying anything.
Although, it is possible to configure only single CA to use SHA2 signature, it doesn’t make any sense, because other CAs in the chain will still use legacy SHA1 and will be the target for a possible attack. There is a golden rule: All PKI should share the same public key algorithm, public key length and signature algorithm among CAs in the tree. Do not make mistakes, when root CA uses 2048 bit RSA public key with SHA1 signature and intermediate CAs use 4096 bit RSA public key with SHA521 signature. It is obvious that your root CA will be the target for an attack, because it uses weakest keys and signatures.
In other words, effective security level of the PKI tree is determined by lowest and weakest properties of CAs in the tree. For example, Root CA is 512 bit RSA and SHA256, Intermediate is ECC ECDS_P256 and SHA1 will result in effective properties: Key algorithm: RSA, Key length: 512, Signature: SHA1.
You see that in this example, resulting security of PKI doesn't look promising even if there is a ECC CA.
When upgrading PKI to use SHA2 the strict direction must be followed: at first, are upgraded CAs on the upper level (Root CAs), then CAs on the 2nd level, then CAs on 3rd level, etc. Simply, CAs are upgraded from top to bottom.
Starting with Windows Server 2008, there is a configuration entry which controls the algorithm used by a CA to sign issued certificate. It can be changed by running the following certutil (there is no GUI equivalent):
certutil -setreg ca\csp\CNGHashAlgorithm sha256
and restart certificate services. When done, renew root CA certificate. When prompted, select to generate new key pair. Distribute new root CA certificate among clients (by publishing in Active Directory, group policies, standalone clients, mobile devices, etc.).
Repeat this procedure on intermediate CAs. The only difference between root CA and intermediate CA certificate renewal is that renewal request from intermediate CAs must be submitted to parent CA, while root CA will generate self-signed certificate.
More details about CA certificate renewal procedure:
Although, these articles are written against Windows Server 2003, nothing was changed till Windows Server 2012 R2 (the most modern OS for the article publishing date).
Post your comment: