Alternative timestamping services for Authenticode

开发者_高级运维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 :)

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.

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

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

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

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

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.

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

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.

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