Alternative Zeitstempeldienste für Authenticode

Wir führen für alle unsere Produktions-Builds Codesignaturen und Zeitstempel durch. Gelegentlich (normalerweise, wenn wir kurz vor RTM (!) Stehen) wird der Zeitstempelserver bei Verisign (" http://timestamp.verisign.com/scripts/timstamp.dll " verwendet ) beschließt "), zeitweise offline zu gehen.

Was sollen wir in diesem Fall tun?

• Muss der Zeitstempelserver von Ihrer Root-Zertifizierungsstelle gehostet werden?
• Gibt es andere im Netzwerk gehostete Zeitstempelserver, die wir anstelle von Verisign verwenden könnten, wenn der Server ausfällt? Vorschläge für andere hochverfügbare und kostenlose Alternativen sind willkommen :)

Ich verwende die folgende Batch-Datei, die maximal 300 Mal wiederholt wird. Es gibt zwei Argumente:% 1 ist der Pfad zu einem Ordner, der die Batchdatei, die Pfx-Datei und die Datei signtool.exe enthält. % 2 ist der vollständige Pfad zur zu signierenden Datei. Sie können dies in Ihrem Visual Studio-Post-Build-Ereignis mit dem Aufruf "$ (SolutionDir) Drittanbieter \ Signierung \ sign.bat" "$ (SolutionDir) Drittanbieter \ Signierung" "$ (TargetPath)" aufrufen. Ich habe diese Batchdatei geändert Verwenden Sie in jeder Iteration unterschiedliche Zeitstempelserver. Derzeit werden Comodo, Verisign, GlobalSign und Starfield verwendet. Hoffentlich ist dies das ultimative Signaturskript;)

@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

Ich habe auch http://timestamp.comodoca.com in die vertrauenswürdigen Sites eingefügt (danke Vince). Ich denke, das kann ein wichtiger Schritt sein. Ich habe auch die Stammzertifikate auf dem PC aktualisiert.

Ich bin nicht sicher, ob der Zeitstempelserver der Stammzertifizierungsstelle gehören muss oder nicht.

Wir verwenden http://timestamp.comodoca.com/authenticode (und haben ein Comodo-Authenticodeode-Zertifikat), haben jedoch tatsächlich ein ähnliches Problem, da der Server gelegentlich einen Fehler oder eine Zeitüberschreitung aufweist. Wir signieren als Teil eines nächtlichen (oder On-Demand-) Builds auf unserem Continuous Integration Server nur für Release-Builds (nicht für Debug-Builds).

Ich habe das (meistens) auf zwei Arten umgangen:

• Wenn der Aufruf von signtool.exe fehlschlägt, wird er (sofort) noch zweimal versucht
• Das Build-Skript, mit dem jede Exe in einem Schritt signiert wurde (und wir haben mehrere als Teil unseres Produkts), wird jetzt einzeln ausgeführt - dauert etwas länger, schlägt jedoch weniger wahrscheinlich fehl

Zwischen diesen sind Build-Fehler, die durch Zeitstempel-Serverprobleme verursacht wurden, von ein- oder zweimal pro Woche auf praktisch nie gestiegen.

BEARBEITEN: Ich habe eine MSBuild-Aufgabe, die dies ausführt (und ein außerhalb des Repositorys gespeichertes Zertifikatkennwort liest ), unter https://gist.github.com/gregmac/4cfacea5aaf702365724

Es funktioniert gut, indem die URL des verisign-Zeitstempels durch eine der folgenden ersetzt wird:

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

Der VeriSign-Zeitstempelservice ist kostenlos. Das mag vielleicht der Grund sein, warum die Zuverlässigkeit nicht ausreichend ist. Sie geben ihm keine Wartung ein Budget!

Das ist definitiv ein großes Problem. Zeitverschwendung aufgrund fehlgeschlagener Builds aufgrund von Code-Zeitstempelfehlern ist ein wachsendes Problem in der gesamten Softwareentwicklungsbranche. Sicher, Sie können ein komplexes Skript schreiben, um es zu durchlaufen, bis Sie einen Arbeitszeitstempelserver finden. Aber wirklich?

Wir sollten besser verlangen. Wir zahlen viel für diese Zertifikate.

Beachten Sie, dass ich später alternative Zeitstempelserver gefunden habe, von denen nur wenige gehört haben, dass sie in Zeiten, in denen Verisign und Comodo nicht verfügbar sind (normalerweise während der Arbeitszeit an Arbeitstagen), in Ordnung sind.

Jeder Zeitstempelserver kann verwendet werden: Ich habe kürzlich vom Zeitstempelserver meines Ausstellers zu Verisign gewechselt, da ich festgestellt habe, dass der Server von GlobalSign unzuverlässig ist. Darüber hinaus betreibt Thawte keinen eigenen Zeitstempelserver, empfiehlt jedoch die Verwendung von Verisigns.

Normalerweise können Sie einen beliebigen Zeitstempeldienst verwenden. Obwohl die meisten Zertifizierungsstellen einen Zeitstempeldienst anbieten. Beispiele

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 war offiziell EOL im Backend von 2019 für weitere Informationen, die sie auf die unten stehende Frage beantwortet hat.

http-timestamp-verisign-com-scripts-timstamp-dll-nicht verfügbar

Ich hatte das gleiche Problem. Der Verisign-Server war für einige Dateien, die ich zu signieren versuchte, irgendwann nicht erreichbar (andere Dateien im selben Build wurden jedoch korrekt signiert).

Normalerweise versuche ich es erneut und es funktioniert, aber heute auf keinen Fall.

Nach einigen ungenutzten Recherchen im Internet habe ich versucht, http: //*.verisign.com in vertrauenswürdige Zonenseiten zu stellen, und es funktioniert ... Schließlich weiß ich nicht, ob der Server ein Problem hatte und jetzt funktioniert oder ob ich das getan habe Das Richtige, werde ich in den nächsten Tagen sehen, denke ich. Hoffe es kann anderen helfen, die blockiert sind.

Die Serverkonfiguration: Windows Server 2003 SP2, IE8, erweiterte Sicherheit aktiviert.

Sie können Jsign anstelle von signtool verwenden, um Ihre Builds zu signieren und mit einem Zeitstempel zu versehen. Es unterstützt das Failover auf alternative Zeitstempeldienste.

Die Befehlszeilensyntax sieht folgendermaßen aus:

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

Sie können auch die Anzahl der Versuche (mit --tsretries) und die Verzögerung zwischen den Versuchen (mit --tsretrywait) konfigurieren .