A time ago I quoted a Windows PKI team announce about SHA1 Deprecation Policy by Microsoft.
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.
Demystification
Myth 1 – all certificates must have SHA2 (or better) signature after the date
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.
Myth 2 – certificates must use CNG in order to support SHA2
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.
- In fact, there is no relation between CNG and SHA2.
- Second, it doesn’t matter what public key algorithm is used in end-entity certificate. It is not stored in the certificate.
- Signature is generated by a signing authority, so all SHA2-related concerns are about CAs.
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.
Myth 3 – I need to set up new CAs from scratch and decommission old CAs, because there is no way to change the signing algorithm of CA certificate.
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.
How to move to SHA2?
Before I provide exact steps to do this, I’ll talk about key points you need to understand prior modifying anything.
Few things to know
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.
Upgrade Direction
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.
Upgrading CAs
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:
- Renewing a certification authority
- Renew a root certification authority
- Renew a subordinate certification authority
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).
Is it really necessary to upgrade the root or subordinate CA certificates? Based on the note at the bottom of this Google article, it sounds like it isn't: http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html
> Is it really necessary to upgrade the root or subordinate CA certificates? if you would read this article carefully you would find that this is not a requirement for private CAs.
Your article says that it is only important to use SHA-256 for the public key. Therefore can I assume that you can have a SHA-256 certificate issued by a CA even if the CSR is signed using a SHA-1 private key? Any more information about the end-to-end process from generating the CSR and what parts of that are important and how the CA takes the CSR and signs it would be great. Also I am confused how a the CA appears to be able to modify the DN contained in the CSR when they sign it. They seem to be able to change the OU however I understood that the DN was signed by our private key so was not changeable? Any info appreciated.
> Therefore can I assume that you can have a SHA-256 certificate issued by a CA even if the CSR is signed using a SHA-1 private key? yes it is possible. Moreover, in Windows CA there is no way (at this point) to prevent SHA1-signed requests. > Any more information about the end-to-end process from generating the CSR and what parts of that are important and how the CA takes the CSR and signs it would be great. it is a subject for another story. > understood that the DN was signed by our private key so was not changeable? nope. Signature only proves data integrity and authenticy. CA can modify any request parts (but do not change original request) to construct issued certificate.
I have written a Powershell cmdlet that uses X509Enrollment COM objects to create SHA-256 signed CSRs because I understood that was necessary to ensure SHA-1 was not used anywhere in the certificate chain. From what you are saying this was pointless and I could have used the built in certificate request utility (which always uses SHA1 when it signs the request). To get the hash to use SHA256 I do the following: $HashAlgorithm = "sha256" $HashObjectId = New-Object -ComObject x509Enrollment.CObjectID $HashObjectId.InitializeFromValue(([Security.Cryptography.Oid]($HashAlgorithm)).Value) $PKCS10.HashAlgorithm = $HashObjectId I confirm this creates a sha256 signature on the CSR. Is this a pointless exercise? I find this whole process from start to finish is rather unclear and another blog post that covers this would be really useful. Thanks
you can sign request with sha256 signature. My point here is that you cannot enforce CA to support only modern signature algorithms and prevent SHA1, for example. And certificate might be signed with SHA1 algorithm even if original request was signed with SHA2. > was not used anywhere in the certificate chain I'm afraid, but currently it is not possible to completely avoid SHA1. Several calculated values (for example, SKI, AKI extensions, thumbprint) must use SHA1 hashing algorithm, because it is mandated by RFC.
>>CA can modify any request parts (but do not change original request) to construct issued certificate. When the CA receives the signed CSR which parts can they change? If they can change the DN then I cannot understand what the point in signing it was. Is there any part of the CSR that cannot be changed and is therefore specified only by the requester? I thought I understood the CSR process but it seems I was completely wrong. Is there any information you can share or point me to an article that explains this better? Thanks
> Is there any part of the CSR that cannot be changed and is therefore specified only by the requester? only public key algorithm and value. The rest values may be accepted as is, ignored, modified. > I cannot understand what the point in signing it was if CA trusts the requester (by any means, for example, client authentication when request is submitted), then it checks the integrity of the request by validating request signature. If signature is valid, then CA assumes that request was not modified after it was generated and can be processed by a CA, otherwise it is permanently rejected, because request may contain fraudulent data. This is the only purpose of the request signing. Id doesn't mean that CA will use all settings from the request. CA follows policy module rules to construct certain type of certificate. > Is there any information you can share or point me to an article that explains this better? I'm not aware about any.
There was a similar question posted above at 2014.12.16. 12:17 for which your response was a little ambiguous - could you please advise: can you use IIS Manager to create a CSR which can be used to request a SHA-256 compliant certificate from say Symantec (or any other commercial CA)? Or do we have to use certreq.exe to generate the request?
> can you use IIS Manager to create a CSR which can be used to request a SHA-256 compliant certificate from say Symantec (or any other commercial CA)? yes. And no special actions are necessary, because certificate signature is applied by CA service, not by IIS.
Beware! Take backup before running the certutil command changing the hash algoritm. If you specify the algorithm in lower case letter (sha256) you break the certsvc. It fails to start with the error: WsResetMetadata 0xd00000bb (-805306181) This happened to me on a w2008 R2 CA
Beware! Take backup before running the certutil command changing the hash algoritm. If you specify the algorithm in lower case letter (sha256) you break the certsvc. It fails to start with the error: WsResetMetadata 0xd00000bb (-805306181) This happened to me on a w2008 R2 CA
> If you specify the algorithm in lower case letter (sha256) you break the certsvc you are incorrect. Algorithm name specification is case-insensitive. Something else broke your CA server.
Strange... I thought first it was the algorithm itself causing the error so I rolled back to sha1 (lower case) Same error. Articles on the web suggested database corruption, so I ran different esentutl commands telling me that the db was ok. Then I manually edited the setting in registry to upper case SHA1 and, wow, the service started. Edited manually again to SHA256 and it still worked... May be you are right - it could be a coincident. I'll try it again on my sub-ordinate. (it's all in a test environment).
Result from my Intermediate policy CA:
C:\CERTSRV>certutil -setreg ca\csp\CNGHashAlgorithm sha256
SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\
Here are results from my CA: C:\>certutil -setreg ca\csp\CNGHashAlgorithm sha256 SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\contoso-DC2-CA\csp: Old Value: CNGHashAlgorithm REG_SZ = sha1 New Value: CNGHashAlgorithm REG_SZ = sha256 CertUtil: -setreg command completed successfully. The CertSvc service may need to be restarted for changes to take effect. C:\>net stop certsvc && net start certsvc The Active Directory Certificate Services service is stopping. The Active Directory Certificate Services service was stopped successfully. The Active Directory Certificate Services service is starting. The Active Directory Certificate Services service was started successfully. C:\> I also checked all my production CAs and everywhere "sha384" is in lowercase. And haven't heard that casing is a problem.
I ran through the steps and when I renew the certificate I still get sha-1.
Are there any other steps I need to do?
I am on a 2008 R2 Certificate Authority. It was upgraded from a 2003 Certificate Authority.
Did you restart CA service after algorithm change? For better support I would suggest to start a thread on TechNet: https://social.technet.microsoft.com/Forums/en-US/home?forum=winserversecurity
Post your comment:
Comments: