Alternative timestamping services for Authenticode

Question

We perform code signing and timestamping for all our production builds. Occasionally (usually when we are about to RTM (!)) the timestamp server at Verisign ("http://timestamp.verisign.com/scripts/timstamp.dll") decides to go offline intermittently.

What should we do in this case?

• Does the timestamp server have to be hosted by your root certification authority?
• Are there any other network-hosted timestamp servers we could use instead of Verisign if their server is down? Suggestions for other highly available and free alternatives are welcome :)

Cuzco

Answer 1

I use the following batch file which loops a max of 300 times. There are two arguments, %1 is the path to a folder containing the batch file, pfx file and signtool.exe. %2 is the full path to the file being signed. You can call this in your visual studio post build event with something like call "$(SolutionDir)thirdparty\signing\sign.bat" "$(SolutionDir)thirdparty\signing" "$(TargetPath)" I have modified this batch file to use different timestamp servers in each iteration. Currently it uses Comodo, Verisign, GlobalSign and Starfield. Hopefully this is The Ultimate Signing Script ;)

@echo off    

REM create an array of timestamp servers...
set SERVERLIST=(http://timestamp.comodoca.com/authenticode http://timestamp.verisign.com/scripts/timestamp.dll http://timestamp.globalsign.com/scripts/timestamp.dll http://tsa.starfieldtech.com)

REM sign the file...
%1\signtool.exe sign /f %1\comodo.pfx /p videodigital %2

set timestampErrors=0

for /L %%a in (1,1,300) do (

    for %%s in %SERVERLIST% do (

        REM try to timestamp the file. This operation is unreliable and may need to be repeated...
        %1\signtool.exe timestamp /t %%s %2

        REM check the return value of the timestamping operation and retry a max of ten times...
        if ERRORLEVEL 0 if not ERRORLEVEL 1 GOTO succeeded

        echo Signing failed. Probably cannot find the timestamp server at %%s
        set /a timestampErrors+=1
    )

    REM wait 2 seconds...
    choice /N /T:2 /D:Y >NUL
)

REM return an error code...
echo sign.bat exit code is 1. There were %timestampErrors% timestamping errors.
exit /b 1

:succeeded
REM return a successful code...
echo sign.bat exit code is 0. There were %timestampErrors% timestamping errors.
exit /b 0

I also put http://timestamp.comodoca.com into the trusted sites (thanks Vince). I think that may be an important step. I updated the root certificates on the PC too.

Utilitarian

"choice" has language related problem, so I use: choice /C yn /n /t 2 /d y >NUL – Filberte

Using a similar script I'd written, I discovered a problem in that if ANY command returned a non-zero value, MSBuild would consider such an error, and thus declare the project as failed. My script first attempted to see if signing was even necessary. I'm still working on it. Did you have such trouble? A second level of abstraction may solve it, I suppose. – Erse

Im just chipping in here. I know this is an old answer. But this script is "nearly" perfect and so I'd like to just chip in my change. When the script is run as a post-build event. If a timestamp fails but a following timestamp is succesful, the build still fails because MSBuild spys on the happenings of signtool.exe and sees a failure, thusly thinks it's a failure. I have had this happen within VS2012 and from a build machine. My fix is to change the timestamp to abstract it into another cmd so MSBuild cant spy as such: start /wait "Sign Tool" /D "%1" "signtool.exe" timestamp /t %%s %2 – Deleterious

I don't understand the "and retry a max of ten times..." part. The %%a variable is never used. Is there a typo in the for loop or in the comment? – Klinger

Additional note to flobadob's excellent answer. If you are going to use this in a Post-Build step in visual studio, you will need to use the "Call" statement. See this post: Visual Studio Multiple Post Build Commands – Empirin

I wrote a similar PowerShell script, inspired by this script. – Pinkham

For sha256 you need to use /tr "sha256timestamp.ws.symantec.com/sha256/timestamp" now which is quite fast by the way – Jackie

For everybody wondering. Yes that value after /p is the *.pfx password. – Kal

If you're using this script in a PostBuildEvent and the first try fails but the next one is succesful, the build fails because msbuild tries to be too smart and intercepts the information written to the console and to the error console and interprets there is an error even the ERRORLEVEL is 0. One solution can be a proposed here https://mcmap.net/q/103907/-postbuild-event-fails-in-visual-studio-after-signtool-exe-error is to redirect both the standard output and the error output to nul so the call to signtool is %1\signtool.exe timestamp /t %%s %2 2>nul 1>nul – Unpolitic

Answer 2

I'm not sure if the timestamp server has to be owned by the root CA or not.

We use http://timestamp.comodoca.com/authenticode (and have a Comodo authenticode certificate) but actually have a similar issue, in that their server seems to give an error or time out occasionally. We do signing as part of a nightly (or on-demand) build on our continuous integration server for Release builds only (not for Debug builds).

I got around this (mostly) in two ways:

• If the call to signtool.exe fails, it tries again (immediately) twice more
• The build script used to sign every exe in one step (and we have several as part of our product), and now it does one-by-one - takes slightly longer, but is less likely to fail

Between these, build failures caused by timestamp server issues have gone from once or twice a week thing to virtually never.

EDIT: I have an MSBuild task that does this (as well as reads a certificate password stored outside the repository) at https://gist.github.com/gregmac/4cfacea5aaf702365724

Alvita

Answer 3

It works nicely by replacing the verisign timestamp url by one of these:

http://timestamp.comodoca.com/authenticode
http://www.trustcenter.de/codesigning/timestamp

Tracitracie

It seems timestamping is no longer available from trustcenter.de: "Symantec All Products and Services provided by TC TrustCenter GmbH are no longer available. Any questions pertaining to this should be directed to: Symantec TC TrustCenter 24/7 Phone Support Phone: [phone] or [phone]" – Iconostasis

Answer 4

You can usually use any time stamping service you want. Although most CA's will provide a time stamping service. Examples

http://timestamp.globalsign.com/scripts/timstamp.dll
http://timestamp.comodoca.com/authenticode
http://www.startssl.com/timestamp
http://timestamp.digicert.com?alg=sha1
http://timestamp.digicert.com?alg=sha256

timestamp.verisign.com was officially EOL at the backend of 2019 for more information see my answer on the question below.

http-timestamp-verisign-com-scripts-timstamp-dll-not-available

Shani

been looking for the digicert alg specification! Where is this documented? – Witmer

knowledge.digicert.com/alerts/… hope this helps – Shani

new link knowledge.digicert.com/solution/SO912.html – Shani

Answer 5

Any timestamp server can be used: I recently switched from my issuer's timestamp server to Verisign since I found that GlobalSign's server was unreliable. Furthermore, Thawte don't run their own timestamp server but recommend people to use Verisign's.

Schwenk

Well, Thawte is Verisign, so. – Someway

Answer 6

The VeriSign timestamping service is free of charge. That may be perhaps why it's reliability is less than adequate; they don't give it a maintenance a budget!

Definitely this is a big problem. Wasted time due to failed builds from code timestamping failures is a growing issue throughout the software development industry. Sure, you can write a complex script to rotate through, until you find a working time stamping server.. but, really?

We should demand better. We pay A LOT for these certificates.

Note that I later found alternate time-stamp servers that few have heard of were fine to use in periods where Verisign and Comodo is down (usually happens during working hours on workdays).

Erse

Answer 7

I had the same problem. verisign server wasn't reachable sometime for some files I tried to sign (but other files in the same build was correctly signed).

I usually retry and it works but today, no way.

So after some unusefull research on internet I tried to put http://*.verisign.com in trusted zone sites and it works... Finally I don't know if the server had a problem and now works or if I did the right thing, will see in next days I think. Hope it may helps other which are blocked.

The server config: Windows server 2003 sp2, IE8, enhanced security on.

Jackie

Probably coincidental as I find that site simply gets overwhelmed and goes down. You can see it during peak business hours often. – Erse

Answer 8

You can use Jsign instead of signtool to sign and timestamp your builds, it supports failing over to alternative timestamping services.

The command line syntax looks like this:

jsign --keystore keystore.p12 --alias test --storepass password \
      --tsaurl http://timestamp.comodoca.com/authenticode,http://timestamp.globalsign.com/scripts/timestamp.dll \
      application.exe

You can also configure the number of attempts (with --tsretries) and the delay between attempts (with --tsretrywait).

(disclaimer: I'm the author of this open source project)

Took

with a name like that you'd think it could handle JARs – Houdini