6

Not sure why, but when using Code Signing using symantec's timestamp server it sets the expiration for the year 2020. This defeats the purpose of using a timestamp server if my program is still going to expire.

Following is the output when using signtool.exe to verify the timestamp application:

Signature Index: 0 (Primary Signature)
Hash of file (sha1): A6F0CEC09F02900D7977C60A87567031D0D96C7A

    Signing Certificate Chain:
        Issued to: thawte Primary Root CA
        Issued by: thawte Primary Root CA
        Expires:   Wed Jul 16 19:59:59 2036
        SHA1 hash: 91C6D6EE3E8AC86384E548C299295C756C817B81

            Issued to: Thawte Code Signing CA - G2
            Issued by: thawte Primary Root CA
            Expires:   Fri Feb 07 19:59:59 2020
            SHA1 hash: 808D62642B7D1C4A9A83FD667F7A2A9D243FB1C7

                Issued to: My Company
                Issued by: Thawte Code Signing CA - G2
                Expires:   Tue Aug 11 19:59:59 2015
                SHA1 hash: E45B4CBFBA095DB9465F2371C161EF500201561B

    The signature is timestamped: Wed Oct 22 12:15:44 2014
    Timestamp Verified by:
        Issued to: Thawte Timestamping CA
        Issued by: Thawte Timestamping CA
        Expires:   Thu Dec 31 19:59:59 2020
        SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

            Issued to: Symantec Time Stamping Services CA - G2
            Issued by: Thawte Timestamping CA
            Expires:   Wed Dec 30 19:59:59 2020
            SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1

                Issued to: Symantec Time Stamping Services Signer - G4
                Issued by: Symantec Time Stamping Services CA - G2
                Expires:   Tue Dec 29 19:59:59 2020
                SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4


    Successfully verified: SetupGoVivoConsole.exe

    Number of files successfully Verified: 1
    Number of warnings: 0
    Number of errors: 0

Please note that this certificate is set for 1 year expiry, so it is using a timestamp from the server that Symantec provides. According to the (limited) documentation on this subject, using a timestamp server when signing an application should eliminate the application from expiring after the certificate has expired. According to the information I see above, this is not the case as my application will stop functioning on Tue Dec 29 19:59:59 2020.

The command I am using for signtool is as follows :

signtool.exe sign /f "certificate.pfx" /ac "thawte.crt" /p "mypassword" /t http://timestamp.verisign.com/scripts/timstamp.dll "ExecutableToSign.exe"

Kraang Prime
  • 9,981
  • 10
  • 58
  • 124

3 Answers3

6

The purposes of using time stamping is not to make your signature valid forever. Its purposes it to extend the useful life of your signature, from the usual 1 to 3 years that code-signing certificates are valid, to up to 10 years. This is long enough for most needs -who really thinks their code will be traveling through insecure networks (and therefore in need of code signing)and executing 10 years from now.

A time stamping service does nothing more than signing a hash of your own digital signature, plus the current time (as provided by the time stamping service) with the time-stamping sevice's certificate which they (hopefully) guard a lot better than most users of digital certificates and which has been therefore granted a much longer shelf-life. Long-lived as they are, they are still just digital certificates and for basic security every one of those eventually must expire. Given that computers keep getting more powerful even the most secure algorithms and longest signing keys supported today will eventually be insecure.

Note that the expiration date is nothing more than the longest time a certificate (either your code signing one or the time-stamping one) could be valid for. Even today some time-stamping servers use SHA-1 for signing (e.g. that is what your time-stamping example is using). When that algorithm is no longer trusted (and it shouldn't be too long now), all those SHA-1 time stamps will no longer be trusted. That will happen even if the expiration date hasn't been reached.

You should look into other time-stamping services. There are a few out there that will expire a lot further out and use SHA256

If someone ever comes up with an encryption that can never be broken even as computers get better someone will finally create that "forever" timestamp that you ask for. Don't hold your breath.

Cheers!

Aurelio Garcia-Ribeyro
  • 71
  • 1
  • 2
  • RFC 3161 requires the timestamp server certificate to expire: [see section 4.3](https://tools.ietf.org/html/rfc3161#page-15). `The TSA signing key MUST be of a sufficient length to allow for a sufficiently long lifetime. Even if this is done, the key will have a finite lifetime.` The timestamp server certificate expires as a security measure as the algorithms used are not permanently "secure." This way people are always updating the timestamp server certs every now and then with a modern and secure crypto algorithm. – Rex Linder Mar 31 '20 at 19:32
5

I can verify from my painful experience today: an expired timestamp certificate (in my case, Comodo's timestamp cert) will cause Windows (7) to fail the overall code signing check with error 0x80096005.

So yeah, contrary to what's being stated by all cert providers I've looked at, timestamping does not guarantee that your signed executable remains valid in perpetuity.

Look for a timestamp service using a cert. with an expiration date loooong in the future.

Erik Knowles
  • 999
  • 7
  • 15
  • Verisign is one furthest in the future that I am aware of, which isn't that far -- only a couple years. Could you provide a screenshot of how this error appears ? ... if it is trappable perhaps ? – Kraang Prime May 30 '15 at 09:06
  • 3
    The error isn't, e.g., a dialog from Windows. Running signtool with the verify parameter kicks out the error code I listed above. The Digital Signature information on the Properties dialog for an executable signed with a now-expired timestamp cert reads "One of the countersignatures is not valid. The file may have been altered." On viewing the details of the timestamp signature you see "The timestamp signature and/or certificate could not be verified or is malformed." These executables *were* verified as having valid signatures when they were originally built and the cert is not on a CRL. – Erik Knowles Jun 01 '15 at 16:03
1

According to the information I see above, this is not the case as my application will stop functioning on Tue Dec 29 19:59:59 2020.

Why would it stop functioning? Have you tried it? Try to set date on your computer to 2021 and see what happens. Personally I have not tried it but my colleague did. Windows will still run the program. It will validate the application to the date of signing. TSA server certificate was valid then so it should not be a problem.

If you wouldn't have timestamp on the application's signature that would be a problem. After the certificate of signer expires windows will not run the application. But when using timestamp windows does not care about expiry date of TSA certificate.

pepo
  • 8,644
  • 2
  • 27
  • 42
  • Thank you for the reply, however, could you please provide a link to the documentation that shows Windows doesn't look at the timestamp server expiration ? – Kraang Prime Oct 23 '14 at 06:47
  • Signtool uses some `Default Authentication Verification Policy` to verify the signature of application. I tried to find some document about what it is but no luck. The closest I've got is [cryptography tools](http://msdn.microsoft.com/en-us/library/windows/desktop/aa380259(v=vs.85).aspx#introduction_to_code_signing) and [SetReg tool](http://msdn.microsoft.com/en-us/library/windows/desktop/aa387700(v=vs.85).aspx). – pepo Oct 23 '14 at 07:58
  • So the application didn't stop functioning, however it did "unsign" it, acting like the program had never been signed. – Kraang Prime Dec 16 '16 at 07:04
  • @SamuelJackson I can still see Digital Signaures in Properties of my old .exe. TSA certificate expired in 2015 and code sign certificate expired also in 2015. – pepo Dec 16 '16 at 12:26