我们为所有生产版本执行代码签名和时间戳。偶尔(通常在我们即将进行RTM(!)时)Verisign的时间戳服务器(“http://timestamp.verisign.com/scripts/timstamp.dll”)决定间歇性地脱机。
在这种情况下我们该怎么做?
答案 0 :(得分:82)
我使用以下批处理文件,最多循环300次。有两个参数,%1是包含批处理文件,pfx文件和signtool.exe的文件夹的路径。 %2是要签名的文件的完整路径。您可以在Visual Studio post build事件中调用此方法,例如调用“$(SolutionDir)thirdparty \ signing \ sign.bat”“$(SolutionDir)thirdparty \ signing”“$(TargetPath)” 我已修改此批处理文件以在每次迭代中使用不同的时间戳服务器。目前它使用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上更新了根证书。
答案 1 :(得分:14)
我不确定时间戳服务器是否必须由根CA拥有。
我们使用http://timestamp.comodoca.com/authenticode(并且有一个Comodo authenticode证书),但实际上有一个类似的问题,因为他们的服务器似乎偶尔会给出错误或超时。我们只在发布版本的持续集成服务器上进行夜间(或按需)构建的一部分进行签名(不适用于Debug版本)。
我(主要)以两种方式解决了这个问题:
在这些之间,由时间戳服务器问题引起的构建失败已经从一周一次或两次变为几乎从未发生过。
编辑:我有一个MSBuild任务,可以reads a certificate password stored outside the repository
执行此任务(以及https://gist.github.com/gregmac/4cfacea5aaf702365724)答案 2 :(得分:12)
通过以下其中一个替换verisign时间戳url可以很好地工作:
http://timestamp.comodoca.com/authenticode
http://www.trustcenter.de/codesigning/timestamp
答案 3 :(得分:7)
可以使用任何时间戳服务器:我最近从发行者的时间戳服务器切换到Verisign,因为我发现GlobalSign的服务器不可靠。此外,Thawte不会运行他们自己的时间戳服务器,而是recommend人使用Verisign。
答案 4 :(得分:7)
您通常可以使用所需的任何时间戳服务。尽管大多数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-not-available
答案 5 :(得分:6)
VeriSign时间戳服务是免费的。这可能也许是为什么它的可靠性不够;他们没有给维护预算!
这肯定是大问题。由于代码时间戳失败构建失败而浪费的时间是整个软件开发行业中日益严重的问题。当然,你可以编写一个复杂的脚本来旋转,直到你找到一个工作时间标记服务器..但是,真的吗?
我们应该要求更好。我们为这些证书付了很多钱。
请注意,我后来发现很少有人听说过的备用时间戳服务器可以在Verisign和Comodo停机期间使用(通常在工作日的工作时间内发生)。
答案 6 :(得分:3)
我遇到了同样的问题。对于我尝试签名的某些文件,某些时候无法访问verisign服务器(但是同一版本中的其他文件已正确签名)。
我通常会重试并且它可以正常工作,但今天,没办法。
因此,在对互联网进行了一些无用的研究之后,我试图将http://*.verisign.com放在受信任的区域网站中,它的工作原理...... 最后我不知道服务器是否有问题现在有效,或者我做了正确的事情,我会在接下来的几天看到。 希望它可以帮助其他被阻止的人。
服务器配置:Windows server 2003 sp2,IE8,增强了安全性。
答案 7 :(得分:0)
您可以使用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
)。