Material de referencia

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

• Reglas de 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 habitual para la firma de código.
• Aspectos a tener en cuenta al elegir un servicio de sellado de tiempo en un entorno de producción.

Cálculo del número de firmas

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

Entendido de forma sencilla:

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

Las veces de firma no se calculan según la cantidad de archivos de código fuente, ni según una compilación, un empaquetado o un pipeline de CI/CD.

Por ejemplo:

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

Si una compilación produce:

app.exe
helper.dll
installer.msi

Y los tres archivos se firman por separado, 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 invocación de firma de bajo nivel como KSP, Jarsigner, etc.
4. Si la herramienta de compilación firma automáticamente 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 las reglas de conteo correspondientes.

Solo se cuenta si tiene éxito

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

Las siguientes situaciones 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 firmas.
• Eliminación de firmas existentes.
• Generación de archivos de verificación.

Si el servicio remoto ha devuelto correctamente el resultado de la firma, pero el cliente falla posteriormente al escribir el archivo localmente, agregar la marca de tiempo o ejecutar el procesamiento posterior, la firma remota ya completada se sigue contando como 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 específico y no constituye una nueva operación de firma de código.

Por lo tanto:

Firma de código → genera recuentos de firma
Añadir marca de tiempo → no genera recuentos de firma adicionales
Verificar firma → no genera recuentos de firma

Si el servicio de sello de tiempo es exitoso, solo afecta el resultado del sello de tiempo del archivo firmado final y no significa que se haya ejecutado una firma de código adicional.

SignTool CLI

Uso de sslTrus SignTool CLI:

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 han completado exitosamente:

合计 = 3 次

Firma dual con SignTool CLI

Si utiliza el SignTool CLI estándar y habilita SHA-1 y SHA-2 al mismo tiempo:

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

La CLI ordinaria con doble firma se calcula como una tarea de firma por cliente:

GUI / SignTool CLI 双签 = 1 次

Aquí es donde el flujo de firma de un cliente común se confunde más fácilmente con la llamada de firma subyacente de KSP.

Windows KSP

KSP es el método de integración del proveedor CNG de Windows.

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

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

Por ejemplo:

Operación	Número de firmas
Realizar una firma SHA256 sobre app.exe	1 vez
Realizar primero SHA256 y luego agregar 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 varias operaciones de firma subyacentes sobre el mismo archivo, cada firma remota exitosa se contará por separado.

CSP

CSP es el proveedor tradicional de CryptoAPI de Windows.

CSP también invoca el servicio de firma remota a través del proveedor mediante Microsoft SignTool u otras aplicaciones de Windows.

Al determinar el número de firmas, se debe tomar como referencia la operación de firma remota con clave privada que realmente ocurra.

Si la herramienta firma varios archivos por separado o ejecuta varias firmas sobre el mismo archivo, se deben contar por separado.

Jarsigner

Al usar el proveedor sslTrusJarsigner, el jarsigner estándar invoca 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 debe distinguir entre:

1. El archivo ejecutable dentro del paquete de instalación.
2. El paquete de instalación en sí.

Por ejemplo:

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

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

Las herramientas de empaquetado de aplicaciones de escritorio como Electron Builder y Electron Forge pueden firmar automáticamente varios archivos durante un único 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 archivos ejecutables auxiliares

Por ejemplo:

Artefacto	Veces firmado
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 en función del número real de artefactos firmados y de las veces que se firma cada artefacto.

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

Evaluación rápida

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

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

Se puede entender simplemente como:

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

Nota especial:

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

Servidor de sellado de tiempo

La firma de código normalmente utiliza simultáneamente un servicio de sellado de tiempo.

El sello de tiempo puede demostrar que la 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 verificación.

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

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

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

RFC 3161

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

Flujo básico:

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

Los tokens de sello de tiempo suelen incluir:

• Resumen de datos.
• Hora de emisión del sello de tiempo.
• Política de la TSA.
• Firma digital de la TSA.

El servidor de sello de tiempo no consume cuotas adicionales de firma de código de sslTrus por añadir sellos 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, se debe volver a confirmar la documentación oficial más reciente del proveedor, las políticas de servicio y la disponibilidad.

Microsoft

http://timestamp.acs.microsoft.com

Se utiliza principalmente para el sellado de tiempo RFC 3161.

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

Ejemplo:

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

Microsoft SignTool：

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

Sectigo

http://timestamp.sectigo.com

Soporte:

• Authenticode
• RFC 3161

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

Sectigo tiene requisitos de uso del lado del servicio para llamadas por lotes, y los sistemas de producción deben controlar la frecuencia de las llamadas de acuerdo con su política oficial vigente.

DigiCert

http://timestamp.digicert.com

Compatible con RFC 3161, utilizable en escenarios de firma de código como Microsoft Authenticode.

Certum

http://time.certum.pl

Soporte:

• Authenticode
• RFC 3161

La documentación oficial de firma de código de Certum cubre 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 los documentos oficiales actuales de firma de código.

SSL.com

http://ts.ssl.com

Se admite RFC 3161; no se admite el protocolo tradicional de sellado de tiempo Authenticode.

Si la herramienta de firma de destino o los sistemas antiguos presentan restricciones de compatibilidad con el algoritmo de clave utilizado por la TSA, se debe realizar una validación real antes de la integración en producción.

Comparación de servidores de sellado de tiempo

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

En la tabla, "Compatible" describe la capacidad de protocolo confirmada por la información pública del proveedor correspondiente.

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

Servicios de sellado de tiempo restringidos

Algunos servidores de sellado de tiempo ofrecen el servicio RFC 3161, pero no pueden utilizarse 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 que las IP de salida del llamador estén registradas previamente, por lo que 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 este tipo de servicios utilicen sus propios certificados de CA y TSA.

Por lo tanto, no se puede asumir:

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

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

En entornos de producción, se debe usar la plataforma de destino para verificar realmente los productos de firma.

Verificación en entornos de producción

Antes de agregar 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 han completado las pruebas de verificación de firma con productos de firma reales.

No lo haga solo mediante:

浏览器可以打开
HTTP 返回 200

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

Debe usar la herramienta de firma real para enviar una solicitud de sellado de tiempo y realizar la validación sobre el producto final.

Sugerencias para elegir el sellado de tiempo

Para la firma de código SHA-2 moderna en Windows, normalmente se prioriza un servicio de sellado de tiempo compatible con RFC 3161.

Por ejemplo:

Microsoft
Sectigo
DigiCert
Certum
GlobalSign

La elección final debe considerar de manera integral:

• Sistema operativo de destino.
• Herramienta de firma.
• Cadena de certificados de la TSA.
• Accesibilidad de red.
• Restricciones regionales.
• Límites de frecuencia de llamadas.
• Términos del servicio.
• Acuerdo de nivel de servicio.
• Resultados reales de verificación del producto firmado.

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 y los requisitos del proveedor correspondientes.

Métodos de integración relacionados

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

Escenario de uso	Documentación
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