Windows 10: 2019 SHA-2 Code Signing Support requirement for Windows Update

Source: https://support.microsoft.com/en-us/...ndows-and-wsus

:)

 

2019 SHA-2 Code Signing Support requirement for Windows Update

Source: https://support.microsoft.com/en-us/...ndows-and-wsus

 

SHA-2 Code Signing questions

First and foremost, this is my very first experience with Code Signing.

I bought Standard Code Signing from Certum for 3 years.

It is SHA-2 based:

They are all normal Windows Executables; for end users, both portable and installers.

Questions:

1. Bearing in mind the certificate has been issued 10. 10. 2016, i.e. after 1. 1. 2016, does this somehow influence how the signature will behave? I ask this on behalf of reading about deprecation of SHA-1, e.g.:
   
   
2. Should I also timestamp? What is this good for? Are there any disadvantages of timestamping? I found this, which does not really clear things up:
   
   
3. Supposing I would drop support for XP and Vista, will SHA-2 code signature work properly on Windows 7? I read on DigiCert that SHA-2 Code Signing support on Windows 7 is Partial:
   
   
4. There is a havoc around cross-signing SHA-2 (SHA-256 in particular) and SHA-1. Supposing as I said I will no longer support WinXP and Vista, do I need this?
   

 

SHA-2 Code Signing questions

No, it won't.

Timestamps are a proof by a third party that the signature was in fact made at a specific time, and was not merely the result of you winding back your computer's clock.

So the primary use of timestamps is to prove that the signature was made before the certificate expired – or, more importantly, before it was revoked.

For example, if someone's private signing key leaks and they revoke their certificate, this would normally mean all signatures made with it (past and future) become invalid. However, signatures that were timestamped could remain valid because it is known that they were made before the revocation.

The SHA-1 deprecation in Windows' Authenticode also appears to use timestamping so that old programs signed using SHA-1 would still show as correctly signed, while still disallowing anyone after the cutoff from "back-dating" new signatures.

Since there are quite a few free & public timestamping authorities, there's no reason not to.

First note that SHA-1/SHA-2 is involved in several places – it is used separately when the issuing CA signs your certificate, and when you sign the actual executable (and even when the timestamping authority counter-signs your signature). In other words, there is a chain of signatures, and every single of them has its own hash.

It is also possible that signatures on certificates are validated by different code than signatures on executables, and one could support SHA-2 while the other still doesn't.

So the actual situation is that Windows XP SP3 fully supports certificates signed using SHA-2, it merely doesn't support executables signed using SHA-2. This is mentioned in KB 968730, also this TechNet post.

However, in Authenticode it's possible to add multiple signatures to the same executable (aka dual-signing or nested signing), so you can have a SHA-1-based signature for older systems and a SHA-2-based one for newer ones.

With osslsigncode, you can first make a SHA-1 signature with -h sha1, then run it again with -nest -h sha256 to add a SHA-2 one. The same works with signtool sign /as /fd sha256 /td sha256 (append signature). For example, the nightly PuTTY builds are dual-signed and work on all Windows versions, despite using a SHA-256-signed certificate.

(I'm not counting XP SP2 and older here, since, well.)