timestamp - stamping - Servicios alternativos de sellado de tiempo para Authenticode

time stamping

Question

Realizamos la firma de código y la marca de tiempo para todas nuestras construcciones de producción. Ocasionalmente (por lo general, cuando estamos a punto de RTM (!)) El servidor de marca de tiempo en Verisign (" http://timestamp.verisign.com/scripts/timstamp.dll ") decide desconectarse de forma intermitente.

¿Qué deberíamos hacer en este caso?

• ¿El servidor de la marca de tiempo debe ser alojado por su autoridad de certificación raíz?
• ¿Hay algún otro servidor de marca de tiempo alojado en la red que podamos usar en lugar de Verisign si su servidor no funciona? Sugerencias para otras alternativas altamente disponibles y gratuitas son bienvenidas :)

Answer 1

El servicio de sellado de tiempo de VeriSign es gratuito. Tal vez sea por eso que su confiabilidad es menos que adecuada; ¡no le dan un presupuesto de mantenimiento!

Definitivamente este es un gran problema. El desperdicio de tiempo debido a las compilaciones fallidas a causa de las fallas en la marca de tiempo del código es un problema creciente en la industria del desarrollo de software. Claro, puede escribir un guión complejo para rotar, hasta que encuentre un servidor de sellado de tiempo de trabajo ... ¿pero realmente?

Deberíamos exigir mejor. Pagamos MUCHO por estos certificados.

Tenga en cuenta que más tarde encontré servidores de marca de tiempo alternativos de los que pocos sabían que podían usar en periodos en los que Verisign y Comodo están caídos (generalmente ocurren durante las horas de trabajo los días laborables).

Answer 2

Funciona muy bien reemplazando la URL de marca de tiempo verisign por uno de estos:

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

Answer 3

No estoy seguro si el servidor de marca de tiempo debe ser propiedad de la CA raíz o no.

Usamos http://timestamp.comodoca.com/authenticode (y tenemos un certificado de autentificación de Comodo) pero en realidad tenemos un problema similar, ya que su servidor parece dar un error o tiempo de espera ocasionalmente. Hacemos la firma como parte de una compilación nocturna (o bajo demanda) en nuestro servidor de integración continua para compilaciones de Release solamente (no para compilaciones de Depuración).

Lo solucioné (principalmente) de dos maneras:

• Si la llamada a signtool.exe falla, intenta de nuevo (inmediatamente) dos veces más
• La secuencia de comandos de compilación utilizada para firmar todos los archivos ejecutables en un solo paso (y tenemos varios como parte de nuestro producto), y ahora lo hace uno a uno, tarda un poco más, pero es menos probable que falle.

Entre estos, las fallas de compilación causadas por problemas del servidor de la marca de tiempo han pasado de ser una o dos veces por semana a virtualmente nunca.

EDITAR: tengo una tarea de MSBuild que hace esto (y también lee una contraseña de certificado almacenada fuera del repositorio ) en https://gist.github.com/gregmac/4cfacea5aaf702365724

Answer 4

Se puede utilizar cualquier servidor de marca de tiempo: recientemente cambié de servidor de marca de tiempo de mi emisor a Verisign porque descubrí que el servidor de GlobalSign no era confiable. Además, Thawte no ejecuta su propio servidor de marca de tiempo sino que recommend personas que usen Verisign.

Answer 5

Utilizo el siguiente archivo de proceso por lotes, que se repite un máximo de 300 veces. Hay dos argumentos,% 1 es la ruta a una carpeta que contiene el archivo por lotes, el archivo pfx y signtool.exe. % 2 es la ruta completa al archivo que se está firmando. Puede invocar esto en su evento visual build post de creación con algo como "$ (SolutionDir) thirdparty / signing / sign.bat" "$ (SolutionDir) thirdparty / signing" "$ (TargetPath)" He modificado este archivo por lotes para utilizar diferentes servidores de marca de tiempo en cada iteración. Actualmente utiliza Comodo, Verisign, GlobalSign y Starfield. Con suerte, este es el último guión de firma;)

@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

También puse http://timestamp.comodoca.com en los sitios confiables (gracias Vince). Creo que ese puede ser un paso importante. Actualicé los certificados raíz en la PC también.

Answer 6

Yo tuve el mismo problema. El servidor verisign no era alcanzable en algún momento para algunos archivos que intenté firmar (pero otros archivos en la misma versión se firmaron correctamente).

Normalmente lo intento y funciona, pero hoy, de ninguna manera.

Así que después de algunas investigaciones inútiles en internet intenté poner http: //*.verisign.com en sitios de zona de confianza y funciona ... Finalmente no sé si el servidor tuvo un problema y ahora funciona o si lo hice lo correcto, lo veré en los próximos días, creo. Espero que ayude a otros que están bloqueados.

La configuración del servidor: Windows Server 2003 sp2, IE8, seguridad mejorada.