Referencias

Esta página consolida la información de referencia compartida entre los distintos métodos de integración del servicio de firma de código remota de sslTrus, incluyendo:

• Reglas para el cálculo del número de firmas de código.
• Protocolos de sellado de tiempo Authenticode y RFC 3161.
• Servidores de sellado de tiempo de uso frecuente para firma de código.
• Aspectos a tener en cuenta al elegir un servicio de sellado de tiempo en entornos de producción.

Cálculo del número de firmas

El número de firmas se calcula según las acciones de firma efectivamente completadas.

Entendido de forma sencilla:

一个文件成功完成一次签名 = 一次签名次数

La cantidad de firmas no se calcula según el número de archivos de código fuente, ni según una compilación, un empaquetado o una canalización de CI/CD.

Por ejemplo:

100 个源代码文件
        ↓
编译生成 1 个 app.exe
        ↓
app.exe 成功签名一次
        ↓
1 次签名

Si una sola compilación produce:

app.exe
helper.dll
installer.msi

Y los tres archivos se firman respectivamente, entonces:

签名次数 = 3 次

Reglas básicas

El número de firmas depende principalmente de:

1. Qué archivos u objetos se firman finalmente.
2. Cuántas firmas se completan realmente en cada objeto.
3. Si se utiliza la firma normal del cliente o métodos de firma de bajo nivel como KSP, Jarsigner, etc.
4. Si la herramienta de compilación firma automáticamente archivos EXE, DLL, desinstaladores o paquetes de instalación adicionales.

Los objetos de firma comunes incluyen:

• .exe
• .dll
• .msi
• .msp
• .sys
• .cat
• .jar
• Desinstalador, por ejemplo uninstall.exe

Siempre que un objeto complete con éxito una firma, se calcula según la regla de conteo correspondiente.

Solo se cuenta si la firma es exitosa

Solo cuando el servicio de firma de código remota completa con éxito la firma, se genera el conteo de firmas.

Los siguientes casos generalmente no se cuentan:

• Fallo de autenticación.
• Error de parámetros.
• Certificado no disponible.
• Fallo en la solicitud de red.
• El servidor no devuelve correctamente el resultado de la firma.
• Consulta de certificados.
• Consulta de registros de firma.
• Verificación de firma.
• Eliminación de firmas existentes.
• Generación de archivos de verificación.

Si el servicio remoto ya ha devuelto correctamente el resultado de la firma, pero el cliente falla posteriormente al escribir el archivo localmente, añadir la marca de tiempo o realizar el procesamiento posterior, la firma remota ya completada se sigue contando como una firma exitosa.

La marca de tiempo no se cuenta por separado

La marca de tiempo se utiliza para demostrar que la firma ya existía en un momento determinado y no constituye una nueva operación de firma de código.

Por lo tanto:

Firma de código       → genera recuentos de firma
Agregar sello de tiempo → no genera recuentos de firma adicionales
Verificar firma       → no genera recuentos de firma

¿El servicio de sellado de tiempo fue exitoso? Esto solo afecta el resultado del sellado de tiempo del archivo firmado final y no significa que se haya realizado una firma de código adicional.

CLI de SignTool

Utilice la CLI de sslTrus SignTool:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe

Si la firma es exitosa:

1 个文件 × 1 次成功签名 = 1 次

Por ejemplo:

signtool sign --cert-code CERT_CODE --file app.exe
signtool sign --cert-code CERT_CODE --file helper.dll
signtool sign --cert-code CERT_CODE --file installer.msi

Los tres archivos se completaron con éxito:

合计 = 3 次

Firma dual con SignTool CLI

Si utiliza el SignTool CLI habitual y habilita simultáneamente SHA-1 y SHA-2:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe \
  --sha1=true \
  --sha2=true

Firma dual CLI ordinaria se calcula como una tarea de firma de un cliente:

GUI / SignTool CLI 双签 = 1 次

Aquí es donde se confunde más fácilmente el flujo de firma de un cliente común con las llamadas de firma subyacentes de KSP.

Windows KSP

KSP es el método de integración con el CNG Provider de Windows.

Cuando Microsoft SignTool, MSBuild, Visual Studio, las herramientas de empaquetado de Electron u otro software de Windows invocan la firma de código remota a través de KSP, el recuento se asemeja más a:

底层远程私钥签名调用次数

Por ejemplo:

Operación	Veces de firma
Realizar una firma SHA256 sobre app.exe	1 vez
Primero SHA256, luego añadir SHA1	2 veces
Firmar por separado app.exe, helper.dll, uninstall.exe	3 veces

Por lo tanto:

SignTool CLI 双签 = 1 次
KSP 双签          = 2 次

Si la herramienta realiza múltiples operaciones de firma subyacentes sobre el mismo archivo, cada firma remota exitosa se contará por separado.

CSP

CSP es el Proveedor CryptoAPI tradicional de Windows.

CSP también es invocado por Microsoft SignTool u otras aplicaciones de Windows a través del Proveedor para llamar al servicio de firma remota.

Para determinar el número de firmas, se debe tomar como referencia la operación real de firma remota con clave privada.

Si la herramienta firma varios archivos por separado o firma el mismo archivo varias veces, cada operación debe contarse por separado.

Jarsigner

Al usar el Proveedor sslTrusJarsigner, el jarsigner estándar invocará el servicio remoto de firma de código durante el proceso de firma.

Generalmente:

Operación	Número de firmas
Firmar app.jar	1 vez
Firmar 3 JAR por separado	3 veces
Volver a firmar el mismo JAR una vez más	1 vez adicional
jarsigner -verify	0 veces
Generar keystore para verificación	0 veces

Por lo tanto:

每个 JAR 每次成功完成签名 = 1 次

Paquete de instalación

El paquete de instalación necesita distinguir entre:

1. El archivo ejecutable dentro del paquete de instalación.
2. El propio paquete de instalación.

Por ejemplo:

app.exe       → firma 1 vez
installer.msi → firma 1 vez

entonces:

合计 = 2 次

Si hay otros archivos:

Archivo	¿Está firmado?	Número de firmas
app.exe	Sí	1
helper.dll	Sí	1
driver.sys	Sí	1
installer.msi	Sí	1
Total		4

La cantidad de código fuente, archivos de recursos, imágenes o archivos de configuración incluidos en el paquete de instalación no afecta directamente el número de firmas.

Lo importante es:

最终到底有哪些产物被实际签名

Electron

Electron Builder, Electron Forge y otras herramientas de construcción de aplicaciones de escritorio pueden firmar automáticamente múltiples archivos durante un solo proceso de empaquetado.

Los objetos comunes incluyen:

• Programa principal .exe
• DLL
• Programa de actualización
• Programa de desinstalación
• Paquete de instalación .exe
• MSI
• Otros ejecutables auxiliares

Por ejemplo:

Artefacto	Número de firmas
MyApp.exe	1
ffmpeg.dll	1
update.exe	1
uninstall.exe	1
MyApp Setup.exe	1
Total	5

Por lo tanto:

一次 Electron Build ≠ 一次签名

Debe calcularse según la cantidad real de artefactos firmados y el número de veces que se firma cada artefacto.

Si Electron utiliza KSP y realiza una firma dual en el mismo archivo, ese archivo también puede generar dos firmas remotas.

Determinación rápida

Cuando no se sabe cuántas firmas generará una compilación, puede confirmarse en orden:

1. 最终有哪些文件被签名？
2. 每个文件签了几次？
3. 使用的是 SignTool CLI 还是 KSP / Jarsigner？
4. 构建工具有没有自动签额外文件？

Se puede entender de manera sencilla como:

签名次数 = 成功完成的签名动作数量之和

Atención especial:

GUI / SignTool CLI 双签                = 1 次
KSP 对同一个文件执行两次底层签名       = 2 次
Jarsigner 每个 JAR 每次成功签名         = 1 次
时间戳                               = 0 次
验证签名                             = 0 次

Servidor de sellado de tiempo

La firma de código suele utilizar simultáneamente servicios de sellado de tiempo.

El sello de tiempo puede demostrar que una firma digital ya existía en un momento específico, lo que permite a la parte verificadora juzgar la validez de la firma combinando el certificado de firma, el certificado de sello de tiempo, el estado de revocación y la política de validación.

Existen dos protocolos comunes de sellado de tiempo para la firma de código:

Protocolo	Descripción
Authenticode	Protocolo de sello de tiempo tradicional de Microsoft, utilizado principalmente para la compatibilidad con flujos de firma de código de Windows más antiguos
RFC 3161	Protocolo de sello de tiempo universal, adecuado para escenarios modernos de firma de código

En los escenarios modernos de firma de código, normalmente se prioriza el uso de RFC 3161.

RFC 3161

La solicitud de sello de tiempo RFC 3161 envía el resumen de los datos a sellar, en lugar del archivo original.

Flujo básico:

代码签名
   ↓
计算待时间戳数据摘要
   ↓
发送摘要到 TSA
   ↓
TSA 返回时间戳令牌
   ↓
写入最终签名

Los tokens de sello de tiempo suelen contener:

• El resumen de los datos.
• La hora de emisión del sello de tiempo.
• La política de la TSA.
• La firma digital de la TSA.

El servidor de sello de tiempo no consume usos adicionales de firma de código de sslTrus por añadir el sello de tiempo.

Servidores de sello de tiempo habituales

Los siguientes endpoints son adecuados para escenarios comunes de firma de código.

Antes de usarlos en producción, debe volver a confirmar la documentación oficial más reciente, las políticas de servicio y la disponibilidad de cada proveedor.

Microsoft

http://timestamp.acs.microsoft.com

Se utiliza principalmente para marcas de tiempo RFC 3161.

Adecuado como candidato de marca de tiempo en escenarios modernos de firma de código para Windows.

Ejemplo:

--timestamp-rfc3161=http://timestamp.acs.microsoft.com

Microsoft SignTool：

/tr http://timestamp.acs.microsoft.com
/td SHA256

Sectigo

http://timestamp.sectigo.com

Admite:

• Authenticode
• RFC 3161

Se puede utilizar en Windows y otras herramientas de firma de código que soporten los protocolos correspondientes.

Sectigo tiene requisitos de uso del lado del servicio para llamadas masivas; los sistemas de producción deben controlar la frecuencia de las llamadas según su política oficial actual.

DigiCert

http://timestamp.digicert.com

Compatible con RFC 3161, puede utilizarse para escenarios de firma de código como Microsoft Authenticode.

Certum

http://time.certum.pl

Soporte para:

• Authenticode
• RFC 3161

Los materiales oficiales de firma de código de Certum cubren escenarios de firma de Windows y Java JAR.

GlobalSign

http://timestamp.globalsign.com/tsa/r45standard

Actualmente, los materiales de firma de código de GlobalSign utilizan esta dirección de marca de tiempo RFC 3161.

No se recomienda seguir utilizando direcciones históricas de GlobalSign que ya no figuran en la documentación oficial actual de firma de código.

SSL.com

http://ts.ssl.com

Admite RFC 3161 y no admite el protocolo tradicional de marca de tiempo Authenticode.

Si la herramienta de firma de destino o el sistema antiguo tiene limitaciones de compatibilidad con el algoritmo de clave utilizado por la TSA, se debe realizar una verificación real antes de la integración en producción.

Comparación de servidores de marca de tiempo

Proveedor	Dirección	Authenticode	RFC 3161
Microsoft	http://timestamp.acs.microsoft.com	Sin confirmar	Compatible
Sectigo	http://timestamp.sectigo.com	Compatible	Compatible
DigiCert	http://timestamp.digicert.com	Sin confirmar	Compatible
Certum	http://time.certum.pl	Compatible	Compatible
GlobalSign	http://timestamp.globalsign.com/tsa/r45standard	Sin confirmar	Compatible
SSL.com	http://ts.ssl.com	No compatible	Compatible

En la tabla, “Compatible” describe la capacidad del protocolo confirmada por la documentación pública del proveedor correspondiente.

Las políticas del servicio de marca de tiempo pueden cambiar; antes de configurar en producción, se debe volver a verificar la documentación oficial actual del proveedor.

Servicios de marca de tiempo restringidos

Algunos servidores de marca de tiempo, aunque ofrecen servicio RFC 3161, no se pueden usar directamente como TSA pública anónima.

QuoVadis

Las direcciones públicas de RFC 3161 incluyen:

http://ts.quovadisglobal.com/eu
http://ts.quovadisglobal.com/ch

Este servicio requiere el registro previo de la IP de salida del llamador; por lo tanto, es necesario completar la autorización correspondiente antes de la integración.

Apple

http://timestamp.apple.com/ts01

Pertenece al servicio de sellado de tiempo utilizado en el ecosistema de firma de código de Apple.

No debe utilizarse directamente como servidor de sellado de tiempo universal para Windows Authenticode.

Servicio de sellado de tiempo de prueba

Algunos servicios públicos RFC 3161 son más adecuados para pruebas de protocolo, en lugar de usarse directamente como TSA de firma de código en producción.

Por ejemplo:

https://freetsa.org/tsr

Es posible que estos servicios utilicen sus propios certificados CA y TSA.

Por lo tanto, no se puede asumir:

Windows
macOS
Java
其他代码签名验证器

De forma predeterminada, todos confiarán en su cadena de certificados.

En el entorno de producción se debe utilizar la plataforma de destino para verificar realmente los productos de firma.

Verificación en el entorno de producción

Antes de incorporar un servidor de sellado de tiempo a la configuración de producción, se recomienda confirmar al menos lo siguiente:

1. La documentación oficial del proveedor de servicios publica claramente este endpoint.
2. El proveedor de servicios admite explícitamente el protocolo de sellado de tiempo requerido.
3. Se utiliza SHA-256 o un algoritmo de resumen de sellado de tiempo más seguro.
4. El sistema de destino puede verificar la cadena de certificados completa de la TSA.
5. El DNS, el proxy, el firewall y la red de salida pueden acceder de forma estable a la TSA.
6. Se han confirmado el método de autenticación, los límites de velocidad, las restricciones regionales y los términos del servicio.
7. Se ha completado la prueba de verificación de firma utilizando productos de firma reales.

No se base únicamente en:

浏览器可以打开
HTTP 返回 200

Determine si el servidor de sellado de tiempo es adecuado para la firma de código.

Debe utilizar la herramienta de firma real para enviar una solicitud de sellado de tiempo y realizar la validación del artefacto final.

Sugerencias para elegir el sellado de tiempo

Para la firma de código SHA-2 moderna de Windows, generalmente se recomienda priorizar los servicios de sellado de tiempo compatibles con RFC 3161.

Por ejemplo:

Microsoft
Sectigo
DigiCert
Certum
GlobalSign

La elección final debe considerar de manera integral:

• El sistema operativo de destino.
• La herramienta de firma.
• La cadena de certificados TSA.
• La accesibilidad de red.
• Las restricciones regionales.
• Los límites de frecuencia de llamadas.
• Los términos del servicio.
• El acuerdo de nivel de servicio.
• Los resultados de verificación del producto de firma real.

Si el proveedor de certificados tiene requisitos explícitos para el servicio de sellado de tiempo, se debe priorizar el cumplimiento de la política de certificados correspondiente y los requisitos del proveedor de servicios.

Métodos de integración relacionados

Los diferentes métodos de integración utilizarán las reglas de número de firmas y sellado de tiempo de esta página:

Escenario de uso	Documento
SignTool CLI	Herramienta de cliente
Windows KSP / CSP	Windows Provider
Jarsigner	Integración con Java
GitHub Actions, Electron Builder, Advanced Installer	CI/CD y herramientas de compilación
Llamada directa a la interfaz de firma remota	Integración con API