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