Services d’horodatage alternatif pour Authenticode

Nous effectuons la signature de code et l’horodatage pour toutes nos versions de production. De temps en temps (généralement lorsque nous sums sur le sharepoint RTM (!)), Le serveur d’horodatage de Verisign (” http://timestamp.verisign.com/scripts/timstamp.dll “) décide de se déconnecter par intermittence.

Que devrions-nous faire dans ce cas?

  • Le serveur d’horodatage doit-il être hébergé par votre autorité de certificateion racine?
  • Existe-t-il d’autres serveurs d’horodatage hébergés sur le réseau que nous pourrions utiliser à la place de Verisign si leur serveur est en panne? Les suggestions pour d’autres alternatives hautement disponibles et gratuites sont les bienvenues 🙂

J’utilise le fichier batch suivant, qui boucle 300 fois maximum. Il existe deux arguments,% 1 est le chemin d’access à un dossier contenant le fichier de commandes, le fichier pfx et signtool.exe. % 2 est le chemin d’access complet au fichier en cours de signature. Vous pouvez appeler ceci dans votre événement Visual Studio Post Build avec quelque chose comme l’appel “$ (SolutionDir) thirdparty \ signed \ sign.bat” “$ (SolutionDir) thirdparty \ signed” “$ (TargetPath)” utiliser différents serveurs d’horodatage dans chaque itération. Actuellement, il utilise Comodo, Verisign, GlobalSign et Starfield. J’espère que c’est le script de signature ultime;)

@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 

Je mets aussi http://timestamp.comodoca.com dans les sites de confiance (merci Vince). Je pense que cela peut être une étape importante. J’ai également mis à jour les certificates racine sur le PC.

Je ne suis pas sûr si le serveur d’horodatage doit appartenir ou non à l’autorité de certificateion racine.

Nous utilisons http://timestamp.comodoca.com/authenticode (et avons un certificate Comodo Authenticode) mais nous avons en fait un problème similaire, en ce sens que leur serveur semble occasionnellement commettre une erreur ou un dépassement de temps. Nous faisons de la signature dans le cadre d’une compilation nocturne (ou à la demande) sur notre serveur d’continuous integration pour les versions Release uniquement (pas pour les versions Debug).

Je l’ai contourné (principalement) de deux manières:

  • Si l’appel à signtool.exe échoue, il tente à nouveau deux fois (immédiatement)
  • Le script de construction utilisé pour signer chaque exe en une seule étape (et nous en avons plusieurs dans le cadre de notre produit), et maintenant il le fait un par un – prend légèrement plus de temps, mais risque moins d’échouer

Entre ceux-ci, les échecs de construction causés par les problèmes de serveur d’horodatage sont passés d’une fois ou deux fois par semaine à des choses pratiquement jamais.

EDIT: J’ai une tâche MSBuild qui fait cela (ainsi que lit un mot de passe de certificate stocké en dehors du référentiel ) à https://gist.github.com/gregmac/4cfacea5aaf702365724

Cela fonctionne bien en remplaçant l’url d’horodatage de verisign par l’un de ceux-ci:

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

Tout serveur d’horodatage peut être utilisé: J’ai récemment basculé du serveur d’horodatage de mon émetteur à Verisign, car j’ai constaté que le serveur de GlobalSign n’était pas fiable. En outre, Thawte ne gère pas son propre serveur d’horodatage, mais recommande aux utilisateurs d’utiliser ceux de Verisign.

Le service d’horodatage VeriSign est gratuit. C’est peut-être pourquoi sa fiabilité est insuffisante. ils ne lui donnent pas un budget d’entretien!

Définitivement c’est un gros problème. Le temps gaspillé dû à des échecs de génération à partir d’échecs d’horodatage de code est un problème croissant dans l’indussortinge du développement logiciel. Bien sûr, vous pouvez écrire un script complexe pour effectuer une rotation, jusqu’à ce que vous trouviez un serveur d’horodatage de travail .. mais, vraiment?

Nous devrions exiger mieux. Nous payons beaucoup pour ces certificates.

Notez que plus tard, j’ai découvert que les serveurs d’horodatage alternatifs dont peu avaient entendu parler pouvaient être utilisés pendant les périodes où Verisign et Comodo étaient en panne (cela se produit généralement pendant les heures de travail les jours ouvrables).

J’ai eu le même problème. Le serveur verisign n’était pas accessible parfois pour certains fichiers que je tentais de signer (mais les autres fichiers de la même version étaient correctement signés).

J’ai l’habitude de réessayer et ça marche mais aujourd’hui, pas question.

Donc, après quelques recherches inutiles sur Internet, j’ai essayé de mettre http: //*.verisign.com dans des zones de confiance et cela fonctionne … Enfin, je ne sais pas si le serveur a eu un problème et fonctionne maintenant ou si je le faisais. bonne chose, verra dans les prochains jours je pense. J’espère que cela peut aider d’autres qui sont bloqués.

La configuration du serveur: Windows Server 2003 sp2, IE8, sécurité renforcée.