3

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:

Secured by the SHA-2 function

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.:

    January 1 2016 - Microsoft products, including Internet Explorer and Chrome, will cease to trust SHA-1 Code Signing certificates (Source)

  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:

    Timestamping should be used if the signature is supposed to be used (to proof authenticity of the document author or data originator) in long term, i.e. longer than one or several days. (Source)

  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:

    Detailed OS Compatibility: Windows 7 Partial (Source)

  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?

7

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.:

No, it won't.

Should I also timestamp? What is this good for? Are there any disadvantages of timestamping?

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.

Supposing I would drop support for XP and Vista, will SHA-2 code signature work properly on Windows 7?

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?

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.)

  • So in case I do want to timestamp and only with sha256, this would do, supposing I have imported the certificate to my local repository: signtool sign /fd SHA256 /a /tr http://time.certum.pl "Test.exe" ? – LinuxSecurityFreak Nov 27 '16 at 10:42
  • 1
    The other advantage of timestamping is that the signed verification will still pass even after your certificate has expired. So if you timestamp now, your app will still run in 4 years' time – Matthew Steeples Nov 27 '16 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.