Authenticode的替代时间戳服务

我们为所有生产版本执行代码签名和时间戳。有时（通常是当我们准备进行RTM（！）时），Verisign的时间戳服务器（“ http://timestamp.verisign.com/scripts/timstamp.dll ”）决定间歇性地脱机。

在这种情况下我们该怎么办？

• 时间戳服务器是否必须由您的根证书颁发机构托管？
• 如果服务器停机，是否还有其他网络托管时间戳服务器可以代替Verisign使用？欢迎其他高可用性和免费替代方案的建议:)

我使用以下最大可循环300次的批处理文件。有两个参数，％1是包含批处理文件pfx文件和signtool.exe的文件夹的路径。％2是要签名的文件的完整路径。您可以在Visual Studio发布后事件中使用“ $（SolutionDir）thirdparty \ signing \ sign.bat”之类的名称来调用此命令。在每次迭代中使用不同的时间戳服务器。目前，它使用Comodo，Verisign，GlobalSign和Starfield。希望这是终极签名脚本;）

@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

我还将http://timestamp.comodoca.com放到了受信任的站点中（感谢Vince）。我认为这可能是重要的一步。我也更新了PC上的根证书。

我不确定时间戳服务器是否必须由根CA拥有。

我们使用http://timestamp.comodoca.com/authenticode（并具有Comodo authenticode证书），但实际上存在类似的问题，因为其服务器似乎偶尔会出现错误或超时。我们在连续集成服务器上作为每晚（或按需）构建的一部分进行签名，仅适用于Release构建（不适用于Debug构建）。

我（主要）通过两种方式解决了这个问题：

• 如果对signtool.exe的调用失败，它将再次（立即）再次尝试两次
• 用于一步一步签名每个exe的构建脚本（而且我们的产品中有多个脚本），现在它一步一步地执行-花费的时间稍长，但失败的可能性较小

在这些问题之间，由时间戳服务器问题引起的构建失败已经从每周一次或两次变为几乎从未发生过。

编辑：我有一个执行此操作的MSBuild任务（以及读取存储在存储库外部的证书密码），网址为https://gist.github.com/gregmac/4cfacea5aaf702365724

通过使用以下其中之一替换verisign时间戳URL，可以很好地工作：

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

免费提供VeriSign时间戳服务。这也许就是为什么它的可靠性不够充分的原因。他们没有给它一个维护预算！

无疑，这是一个大问题。在整个软件开发行业中，由于代码时间戳错误导致的构建失败而浪费时间是一个日益严重的问题。当然，您可以编写一个复杂的脚本来轮流浏览，直到找到可以正常工作的时间戳服务器为止。但是，真的吗？

我们应该要求更好。我们为这些证书支付了很多。

请注意，我后来发现很少有人听说过的备用时间戳服务器可以在Verisign和Comodo宕机（通常在工作日的工作时间）期间使用。

可以使用任何时间戳服务器：由于发现GlobalSign的服务器不可靠，我最近从发行者的时间戳服务器切换到了Verisign。此外，Thawte不会运行自己的时间戳服务器，但建议人们使用Verisign的时间戳服务器。

通常，您可以使用任何所需的时间戳服务。尽管大多数CA都会提供时间戳服务。例子

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在2019年底正式停产，以了解更多信息，她对下面的问题充满信心。

http-timestamp-verisign-com-scripts-timstamp-dll-不可用

我有同样的问题。对于某些我尝试签名的文件，verisign服务器有时无法访问（但同一版本中的其他文件已正确签名）。

我通常会重试，但它仍然有效，但今天没有办法。

因此，在互联网上进行了一些无用的研究之后，我尝试将http：//*.verisign.com放到受信任的区域中，并且可以正常工作...最后，我不知道服务器是否有问题，现在是否可以正常工作，或者我是否做了对的事情，我想在未来几天会看到。希望它可以帮助其他被阻止的人。

服务器配置：Windows Server 2003 sp2，IE8，增强了安全性。

您可以使用Jsign代替signtool来对构建进行签名和时间戳记，它支持故障转移到其他时间戳记服务。

命令行语法如下所示：

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

您还可以配置尝试次数（使用--tsretries）和两次尝试之间的延迟（使用--tsretrywait）。