hudson - visual - signtool.exe no se encontró en la ruta de acceso

¿Cómo uso signtool.exe correctamente en hudson que se ejecuta como un servicio?

Question

Acabo de comprar un certificado de firma de código (autenticode MS) de THAWTE y lo he instalado aparentemente en mi máquina de compilación. He iniciado sesión como usuario y cuando abro un indicador de cmd puedo firmar EXEs utilizando el certificado con signtool.exe.

Desafortunadamente, esta misma línea de comando no funciona en el proceso de hudson que se ejecuta en la máquina.

el mensaje de error que recibo es:

Error de SignTool: No se encontraron certificados que cumplieran con todos los criterios dados.

Supongo que esto se debe a que el servicio hudson se ejecuta con una cuenta diferente a la cuenta con la que ejecuté signtool.exe desde y desde la cuenta que usé para obtener el certificado de thawte.

Entonces, mi pregunta es: ¿Cómo soluciono este problema? Pensé que iba a descargar un archivo de thawte, pero en lugar de eso solo usé IE de alguna manera para instalar mágicamente el certificado en el caché del usuario. Probablemente quiera exportar (o cualquiera que sea el término correcto) a un archivo que pueda almacenar / guardar o usar en cualquier otra máquina.

¿Cómo hago eso y cómo llamo a signtool correctamente con el archivo o el certificado de otro usuario en la cuenta del sistema / servicios?

Answer 1

Esto es un poco viejo ahora, pero tuve un problema similar que vale la pena documentar, pensé.

Tengo un servidor Jenkins CI que se ejecuta en Win2008R2 como un servicio que no pudo encontrar el certificado cuando se ejecuta un trabajo, pero manualmente puedo firmar cualquier cosa en la misma máquina.

signtool sign /sha1 ### file.dll
SignTool Error: No certificates were found that met all the given criteria.

El problema era que el servicio Jenkins se ejecutaba como una máquina local, por lo que pensé que utilizar la respuesta anterior funcionaría.

signtool sign /sm /sha1 ### file.dll

Mismo error. /a tampoco hice nada.

Lo hice funcionar creando un usuario ''Jenkins'' como miembro del grupo de administradores, ejecutando el servicio como usuario ''Jenkins'', iniciando sesión como usuario de Jenkins e instalando el certificado en el almacén de usuarios.

Sí, instalé el certificado en el almacén de la máquina local. Incluso confirmé que la tienda de servicio tenía el certificado utilizando mmc y agregando la cuenta de servicio - Tienda de Jenkins.

Answer 2

Para propósitos de referencia, agregaré nuestras experiencias aquí. Estamos utilizando TeamCity para crear una aplicación firmada ClickOnce. Me tomó varias horas hacer esto correctamente, así que espero que esto le ahorre a alguien más algún tiempo.

Nota: estoy ejecutando esto en un servidor Windows 2k3 que también es un servidor de dominio (sí, lo sé).

1. Utilizamos un certificado de firma de código de GoDaddy . El CSR fue generado con Internet Explorer . Así que al completar el problema con Internet Explorer, básicamente terminé con el Certificado de firma de código instalado en mi propia cuenta.

2. Debido a que necesitaba el certificado en el servidor de compilación, elegí en IE:

   [Extra]> [Opciones de Internet]> [Contenido]> [Certificados]

   Luego hice clic derecho en el certificado y [Exportar] ''ed. Marqué [Exportar clave personal] y elegí el formato PFX con [Exportar todos los certificados] y [Exportar todas las propiedades] (no estoy seguro de si ese último es realmente necesario). Finalmente, después de especificar la ubicación, tuve mi Precious.

3. Ahora estaba listo para un verdadero dolor, pero para evitarte los detalles, me saltaré los desagradables hickups. Como TeamCity se estaba ejecutando bajo la cuenta del sistema, necesitaba tener este certificado en nuestro servidor de compilación bajo esa misma cuenta. Así que en el servidor de compilación, invocé :

   C: /> psexec -i -s cmd

4. Eso me lanzó una línea de comando, corriendo como usuario del sistema. Ahora llamé a mi IE oxidado otra vez:

   C: /> C: / Archivos de programa (x86) / Internet Explorer / iexplore.exe

5. Navegué por los certificados y, en lugar de exportar, elegí Importar y seleccioné el certificado que exporté anteriormente. Dejo que Windows elija dónde almacenarlos.

6. Ahora todo estaba listo para que ClickOnce usara el certificado para firmar nuestra aplicación. Solo teníamos que asegurarnos de que ClickOnce lo supiera. No quería poner nuestro archivo clave en un repositorio de código, así que en mi Visual Studio local en la pestaña [Firma] de las propiedades del Proyecto, marqué [Manifestaciones de ClickOnce] y usé [Seleccionar de la Tienda ...] en lugar de [ Seleccione del archivo ...]. Esto me permitió elegir mi certificado instalado localmente. En ese mismo momento, VS creó una propiedad <ManifestCertificateThumbprint> que es lo más importante para que esto se ejecute en el servidor de compilación.

   Tenga en cuenta que también agregué un servidor de marca de tiempo que no está obligado, pero se recomienda encarecidamente para firmar el software. De lo contrario, su software podría dejar de validar cuando caduque su certificado. Para GoDaddy, el servidor de tiempo es http://tsa.starfieldtech.com .

   También tenga en cuenta que no firmé la asamblea (todavía). Solo digo para que sepas que esto es posible.

7. Ahora el servidor de compilación recogería el archivo de proyecto y la propiedad nueva ManifestCertificateThumbprint, y lo alimentaría a la tarea SignTool. Para poder ejecutar ese, tuve que copiar sobre signtool.exe desde C: / Archivos de programa (x86) / Microsoft SDKs / Windows / v7.0A / Bin a la misma ubicación en el servidor de compilación.

   Se ha realizado una depuración desagradable grave para averiguar por qué no funcionaba el letrero. Saqué herramientas como ProcMon y Process Explorer para averiguar qué claves de registro solicitaban las líneas de comando. Volví a crear la línea de comando real invocada por SignTool y observé los efectos con esas herramientas.

Finalmente, después de mucho desarrollo intenso y dolor de administrador de sistemas, pude implementar nuestra aplicación firmada ClickOnce. ¡Aclamaciones!

Answer 3

Pensé que esto sería un problema simple de resolver. En cambio, se está convirtiendo en una tragedia griega.

El proveedor, Thawte, aparentemente cree que es útil requerir que todas las acciones de certificado se realicen en la misma máquina y navegador desde el que se inició la solicitud. Desafortunadamente en mi caso lo hice desde una máquina con Windows7. Debido a algunas tonterías de MS, eso significa que cuando obtuve el certificado no puedo exportarlo con la clave privada. Eso solo es posible en Win2000 y XP. Así que necesito usar un sistema operativo de 7 años para hacer algo fundamental para mi negocio. Esto es alucinante.

Resulta que ahora estoy esperando que se cumpla la tercera solicitud del certificado.

Answer 4

Tomado de signtool sign -h salida:

/s <name> Specify the Store to open when searching for the cert. The default
is the "MY" Store.
/sm Open a Machine store instead of a User store.

Hacer que esto funcione es un poco molesto ... pude hacerlo funcionar agregando los certificados al almacén de la máquina local y usando el interruptor / sm.

El modificador / s le permite seleccionar qué tienda predefinida utilizar. Desafortunadamente, no puedo encontrar ninguna documentación que enumere cuáles son las opciones disponibles en realidad (@Microsoft signtool mantenedor: ¡documente esto!). Una complicación adicional es que es difícil determinar a qué tienda Hudson ofrece acceso, no es la cuenta de hudson de seguridad local, como cabría esperar.

Nota: La tienda "Personal" que aparece en las vistas de mmc es la tienda "MI" cuando se accede desde signtool.

Afortunadamente, el interruptor / sm nos proporciona una tarjeta para salir de la cárcel sin cargo. Desafortunadamente, esto sería un riesgo de seguridad si su servidor de compilación ejecuta trabajos para varias organizaciones o departamentos. En mi caso, solo lo usa mi grupo, así que esto no me molesta.