Happy Holidays! In this busy time of year, reserve some time for another (hopefully not too expensive) chore that might be unexpected. Due to the industry push to move from the SHA-1 hashing algorithm to the more secure SHA-2 (e.g. SHA256) hashing algorithm, you may need to purchase or renew your certificates, even if they are still valid.
For various reasons, the deadline for action is December 31, 2015.
Call to Action
Ensure that you purchase or renew (and start using) one or more code signing certificates by December 31, 2015.
The required certificates depend on whether you sign User Mode and/or Kernel Mode Windows modules:
- User Mode files (e.g. msi, exe, etc.) must be signed with a SHA-2 certificate starting after December 31, 2015.
- Kernel Mode drivers (e.g. .sys files) can be signed with either a SHA-1 or SHA-2 certificate, but SHA-1 is most compatible — even for Windows 10.
But: December 31, 2015 is the last day you can purchase a SHA-1 certificate.EDIT 12/29/2015: Microsoft has rescinded this deadline.
User Mode Q and A
Q: What happens if I continue to use my old, still valid, SHA-1 certificate after December 31?
A: Windows will ignore your signature as if your files were unsigned.
After these dates have passed, Microsoft software such as Internet Explorer® and Windows® will reject code signing and SSL certificates that use SHA-1.
On Win 7 and above, blocked on 1/1/2020 if time stamped before 1/1/2016, otherwise, blocked after 1/1/2016 for Mark of the Web files.
Q: Will there be compatibility issues if I sign with SHA-2?
A: No, not for User Mode. (Kernel Mode does have compatibility issues, see below.) SHA-2 for User Mode is supported in Windows XP SP3 and later.
This is a list of popular software that supports SHA-2:
Windows XP 3 and above (including Windows 8.1, 8.0 and Vista)
…
Windows Server 2003 and above
Q: I already have a SHA-1 certificate. Do I have to spend money and buy a SHA-2 certificate also?
A: Contact the Certificate Authority (CA) which issued your SHA-1 certificate (e.g. Comodo, DigiCert, GlobalSign, etc.). They should give you a SHA-2 version for free, which has the same expiration as your original SHA-1 certificate.
Q: I already have a valid SHA-2 certificate. Do I need to do anything?
A: No, congratulations, you are good to go! Just make sure you sign with it starting January 1, or earlier.
Kernel Mode Q and A
SHA-1 Certificate Availability
Q: I don’t have a SHA-1 certificate, but I don’t plan to sign kernel mode modules yet. Can I wait to purchase a SHA-1 certificate until I need it?
Q: I currently have a SHA-1 certificate, and it is valid for some time to come. Why do I have to renew it by December 31?
A: December 31 is the last day that you can purchase or renew a SHA-1 certificate. So it is now or never. EDIT 12/29/2015: Microsoft has rescinded this deadline.
CA/Browser Forum
Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. […]
Effective 16 January 2015, CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA-1 algorithm with an Expiry Date greater than 1 January 2017 […]
CAs SHOULD issue SHA-2 only, unless developer is targeting Vista and Server 2008 (for them, CAs MAY issue SHA-1)
Also, I recommend getting a multi-year certificate — On December 7, 2015, I got a SHA-1 version of my DigiCert EV SHA-2 certificate; both are valid through 2018, despite the above warning that the SHA-1 version should expire no later than January 1, 2017 — to minimize the possibility of having to deal with certificate issues again for as long as possible. When it expires, you will be forced to switch to SHA-2 (or SHA-3 or whatever the standard is by then), and deal with whatever rules are in effect.
However, prior to your new SHA-1 certificate expiring, the industry could disqualify it for kernel mode, the same as it did for SHA-1 User Mode (which is disqualified on January 1). So try to strike a balance between getting a certificate for too short or too long a time period.
Q: I already have a SHA-2 certificate. Do I have to spend money and buy a SHA-1 certificate also?
A: Contact the Certificate Authority (CA) which issued your SHA-2 certificate (e.g. Comodo, DigiCert, GlobalSign, etc.). They may give you a SHA-1 version for free, which has the same expiration as your original SHA-2 certificate. I have a DigiCert EV SHA-2 certificate, for which I was given a free SHA-1 certificate with the same 2018 expiration date. I also have a Comodo Authenticode (non-EV) SHA-2 certificate which expires in 2018, and thus far, Comodo has only offered to give me a free SHA-1 certificate that expires on December 31, 2015! So your experience may vary.
The summary on the MadCodeHook forum is that DigiCert and GlobalSign are proven to still issue SHA-1. There is a question of whether businesses are treated differently from individuals.
Q: I already have a SHA-1 certificate with a long time left until it expires. Do I need to do anything?
A: No, congratulations, you are good to go!
SHA-1 vs. SHA-2
Q: Why is SHA-1 better than the newer and the more secure SHA-2?
A: SHA-1 is completely compatible with Windows XP through Windows 10. You can sign one driver package for all of these OS’s, using the tried and true method of using a cross certificate. It remains the only option for XP and Vista.
Q: But won’t my software be more secure if I sign it with with a SHA-2 certificate?
A: No, the purpose of signing software is to prove that you created it. The way it works is when your customer downloads/installs/loads your software, it is Windows that verifies your signature and reports something like “Verified Publisher: <the company name from your certificate>.
An attacker can use the more insecure SHA-1 to more easily spoof your signature on software that the attacker creates (e.g. malware). Such malware would appear to have come from you. Windows would report “Verified Publisher: <the company name from your certificate>. But, this scenario, appalling though it is, can happen even if you sign your legitimate software with SHA-2. An attacker can still sign the malware with a spoofed SHA-1 signature of yours. So you can see that whether you sign your software with SHA-1 or SHA-2, it makes absolutely no difference in the likelihood of being spoofed.
Q: Well, even if my software isn’t more secure by signing with SHA-2, doesn’t signing with SHA-2 make me a good Windows developer and improve the overall Windows ecosystem?
A: No, if Windows accepts SHA-1, it is vulnerable to SHA-1 attacks, such as the above spoofing example. The only thing that strengthens the Windows ecosystem is for Windows to invalidate SHA-1, which so far it is not doing for Kernel Mode (but is for User Mode).
(My speculative opinion with no applicable knowledge: Since MS is invalidating SHA-1 for User Mode, but is continuing to accept SHA-1 for Kernel Mode, perhaps the payoff to do so is not as great as for User Mode.)
SHA-2 Compatibility
Windows 7
Q: I don’t care about XP and Vista. I only care about Windows 7 and later (8, 8.1, 10). Aren’t these OS’s compatible with the more secure SHA-2?
A: For Kernel Mode, Windows 7 is only compatible with SHA-2 if the little-known update KB3033929, released in March, 2015, is installed. For marketing reasons such as lack of customer comprehension and technical ability, and the difficulty of installing in certain cases (e.g. having a multiple-boot configuration of Windows and various distributions of Linux or using a non-Windows boot loader), you may not want to make this update a prerequisite for using your software. (I surely don’t.)
SHA-1 Compatibility
Windows 10
Q: Are there any limitations of signing with SHA-1 for Windows 10?
A: The limitations are described in the Microsoft Code Signing FAQ:
- A cross-signed driver using a SHA-1 or SHA-256 certificate issued after July 29th, 2015 is not recommended for Windows 10.
- A driver signed with any certificate issued after July 29th, 2015, with time stamping, is not recommended for Windows 10.
- A driver signed with any certificate that expires after July 29th, 2015, without time stamping, will work on Windows 10 until the certificate expires.
- Enterprises may implement a device guard policy to modify the driver signing requirements using Windows 10 Enterprise edition. Device Guard provides an enterprise-defined code integrity policy, which may be configured to require at least an attestation-signed driver. [Ed. An “attestation-signed driver” is one that is signed by Microsoft through the SysDev portal (see below).]
At the very least, you can sign with a certificate (SHA-1, non-EV SHA-2 or EV SHA-2) without timestamping, and it will be good until your certificate expires. But timestamping is highly recommended so that the signature lasts “forever”. And even this will work, even though it’s “not recommended” (whatever that means).
Besides this, there is an additional caveat regarding Windows 10 Enterprise. Windows 10 Enterprise supports a feature called Device Guard, which can be used by IT Admins to set a policy disallowing non-EV certificates (including SHA-1 certificates, as EV is not an option for SHA-1).
8 Required:EV Signers In addition to being WHQL signed, this rule requires that drivers must have been submitted by a partner that has an Extended Verification (EV) certificate. All future Windows 10 and later drivers will meet this requirement.
(Personally, I do not have any customers that are running Windows Enterprise that are setting this policy.)
Q: Isn’t an Extended Validation (EV) SHA-2 certificate required for Windows 10?
A: For Windows 10, an expensive and inconvenient EV SHA-2 certificate is required to use the Microsoft SysDev portal. But a non-EV SHA-2 or SHA-1 (all SHA-1 certificates are non-EV) are fine if you don’t use the portal. And it is not required that you use the portal to sign your Kernel Mode software for any current release of Windows.
Q: But I’ve heard that Microsoft requires us to use their SysDev portal for Kernel Mode on Windows 10?
A: No, there is a “transitional policy.”
OSR blog – quoting Microsoft Program Manager James Murray:
Windows 8 style kernel mode code signing will continue to work, as long as the certificate was issued prior to Windows 10 RTM (the cut off).
Q: Um, this says my certificate works only if it was issued before the Windows 10 RTM date. So isn’t it too late to get a SHA-1 certificate for Windows 10?
A: No, as discussed above, the Microsoft Code Signing FAQ now says certificates issued after July 29 will also work, subject to the limitations above. Furthermore, the verbatim quote from Microsoft Program Manager James Murray was originally
Cross-signing will continue to work, as long as the cross-signing certificate was issued prior to Windows 10 RTM (the cut off).
Here, it says it is the cross certificate whose date matters, not the developer’s certificate.
However, in discussion on the OSR NTDEV list, messages #95 – 97, it was discussed that the effective date of the cross certificate could not possibly have any bearing on whether the signature was accepted by Windows 10. As such, the post author intentionally altered the quotation to “clarify” that it was the developer’s certificate that needs to be issued before the RTM. Here is what the blog now says:
Windows 8 style kernel mode code signing will continue to work, as long as the certificate was issued prior to Windows 10 RTM (the cut off).
In hindsight, it seems that the original wording was the correct one, given Microsoft’s clarification that “any certificate” can indeed be used for Windows 10.
David Grayson’s blog and MSDN thread are additional sources that it is the expiration date of the cross certificate that is important:
However, there is a really nice loophole. For backwards compatibility, kernel-mode drivers signed with a valid cross-certificate that pre-dates Windows 10 will continue to pass signing checks in Windows 10. The cross-certificate from GlobalSign was issued long before Windows 10 and it expires on 2021-04-15. Therefore, you should be able to sign kernel-mode drivers for Windows 10 with a regular GlobalSign code-signing certificate until then.
—
Please see the April Fools Day announcement from Microsoft:
http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver-signing-changes-in-windows-10.aspx
It says:
“To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10.”
Microsoft continues to be vague. In addition to the above points, the Microsoft Code Signing FAQ also says
A cross-signed driver using a SHA-1 certificate issued prior to July 29th, 2015 will work on all platforms starting with Windows Vista through Windows 10.
Again, it is not clear whether they are talking about the developer’s SHA-1 certificate, or the cross-signing certificate from the CA.
Anyway, when in doubt, try it! The DigiCert SHA-1 cert issued after the Win 10 RTM date works for me on Win 10 Pro x64 with SecureBoot enabled. I tested on a Windows 8.1 Hyper-V VM (Generation 2, with SecureBoot enabled). The guest OS is Windows 10 Pro x64, Version 1511 (10586.17).
There are other success stories sprinkled into the threads cited in this post.
SHA-1 – Windows 10 Summary
Microsoft clearly wants their SysDev portal (and EV certificates) to be used for Windows 10, and any allowance of non-EV SHA2 and SHA-1 with cross signing is being done with sheer reluctance and non-transparency.
Microsoft has a history of doing this. I am reminded of a similar situation when MS was encouraging converting from the ANSI charset to the Unicode charset. Yes, there are advantages to using Unicode (e.g. easier localization), but also disadvantages (e.g. 2x the memory). And ANSI is still supported in Windows, but is “not recommended”. But I still use it when it make sense.
Despite Microsoft using vague phrases like “not recommended”, SHA-1 works today on Windows 10, and Microsoft has made a pattern of further relaxing its SysDev portal (and EV certificate) requirements. The SHA-1 compatibility with previous Windows versions is so great that I recommend using it for Windows 10 until it is definitively prohibited.
To continue using SHA-1, ensure your certificate is renewed for a sufficient time period.
Free 30 day trial
DCSoft RegEditX – Tweaks for RegEdit
When you RegEdit, remember the ‘X’
DCSoft.com blog 