Servidores de sellado de tiempo para firma de código a nivel global
Alcance del documento
Este artículo recopila los servicios de sellado de tiempo aplicables a la firma de código, con especial atención a los escenarios de Microsoft Authenticode y RFC 3161.
- Fecha de verificación: 18/06/2026.
- Solo se enumeran como extremos públicos las direcciones que se pueden confirmar a partir de la documentación oficial del proveedor.
- Este artículo no es una lista exhaustiva de todos los servicios de sellado de tiempo a nivel mundial. Los servicios cuyos extremos no son públicos, que requieren activación comercial o que solo ofrecen productos de implementación local se describen por separado.
- La disponibilidad, la cadena de certificados y las políticas de acceso de los servicios de sellado de tiempo pueden cambiar; antes de configurar en producción, se debe volver a consultar la documentación más reciente del proveedor.
Protocolos de sellado de tiempo
Existen dos protocolos de sellado de tiempo comunes en la firma de código:
| Protocolo | Descripción |
|---|---|
| Authenticode | Protocolo de sellado de tiempo tradicional de Microsoft, utilizado principalmente para la compatibilidad con flujos de firma de código de versiones antiguas de Windows. |
| RFC 3161 | Protocolo de sellado de tiempo de propósito general, adecuado para escenarios modernos de firma de código; es la opción preferida en entornos de producción. |
La solicitud RFC 3161 envía el resumen de los datos a sellar, no el archivo original. La TSA devuelve un token de sellado de tiempo que contiene el resumen, la hora de emisión, la política y la firma de la TSA. El sellado de tiempo puede demostrar que la firma ya existía en un momento determinado, pero la validez a largo plazo de la firma sigue dependiendo del certificado de firma, del certificado de sellado de tiempo, del estado de revocación y de las políticas del verificador.
Extremos públicos de sellado de tiempo para firma de código
Las siguientes direcciones están claramente indicadas en la documentación oficial vigente y pueden considerarse candidatas para la firma de código. En la tabla, «público» solo significa que el proveedor ha publicado el extremo; no implica que el proveedor se comprometa a un uso ilimitado, incondicional o gratuito de forma permanente.
| Proveedor | Dirección | Authenticode | RFC 3161 | Instrucciones de acceso | Documentación oficial |
|---|---|---|---|---|---|
| Microsoft Artifact Signing | http://timestamp.acs.microsoft.com | No confirmado | ✅ | Microsoft recomienda a los usuarios de Artifact Signing utilizar esta TSA. Adecuada como candidata RFC 3161 para Windows. | Microsoft Artifact Signing |
| Sectigo | http://timestamp.sectigo.com | ✅ | ✅ | La misma dirección admite Authenticode y RFC 3161. El proveedor exige oficialmente un intervalo mínimo de 15 segundos entre solicitudes en llamadas por lotes. | Sectigo Time Stamp Server |
| DigiCert | http://timestamp.digicert.com | No confirmado | ✅ | Indicado oficialmente para el sellado de tiempo RFC 3161 de Microsoft Authenticode. | DigiCert RFC 3161 TSA |
| Certum | http://time.certum.pl | ✅ | ✅ | La documentación oficial de firma de código de Certum utiliza esta dirección para la firma de código de Windows y la firma de archivos JAR de Java. | Certum Code Signing |
| GlobalSign | http://timestamp.globalsign.com/tsa/r45standard | Sin confirmar | ✅ | La documentación actual de firma de código de GlobalSign utiliza esta dirección R45. | Firma de código de GlobalSign en Windows |
| SSL.com | http://ts.ssl.com | ❌ | ✅ | Solo admite RFC 3161. La marca de tiempo predeterminada puede usar claves ECDSA; las herramientas antiguas que solo admiten marcas de tiempo RSA pueden evaluar la dirección /legacy según las instrucciones oficiales. | SSL.com Uso de su certificado de firma de código |
Orden recomendado
Para la firma de código SHA-2, se recomienda evaluar en el siguiente orden:
- Microsoft: adecuado como candidato de marca de tiempo RFC 3161 en Windows.
- Sectigo: admite tanto Authenticode como RFC 3161.
- DigiCert: la documentación oficial confirma explícitamente la compatibilidad con RFC 3161 de Microsoft Authenticode.
- Certum: la documentación oficial de firma de código cubre tanto escenarios de firma de Windows como de Java.
- GlobalSign: utilice la dirección
r45standardde la documentación oficial actual. - SSL.com: úselo solo cuando el llamador admita RFC 3161 y se confirme que puede verificar su certificado de marca de tiempo y el tipo de clave.
El orden indica el grado de coincidencia con los escenarios comunes de firma de código de Windows y no constituye una garantía de calidad del servicio, validez legal o nivel comercial. En entornos de producción, la elección debe basarse en el sistema operativo de destino, la salida de red, la cadena de validación, la accesibilidad regional y el acuerdo de servicio del proveedor.
Servicios restringidos o específicos del ecosistema
QuoVadis
QuoVadis publica las siguientes direcciones RFC 3161:
http://ts.quovadisglobal.com/euhttp://ts.quovadisglobal.com/ch
La política oficial exige registrar primero la IP de salida del llamador en DigiCert, por lo que no puede utilizarse como TSA público anónimo. Antes de la integración, complete la autorización y confirme que la política seleccionada y la cadena de certificados cumplen con el entorno de validación de destino.
Documentación oficial: DigiCert/QuoVadis Timestamp Server
Apple
Apple opera su propia PKI de sellado de tiempo y publica la Apple Timestamp CA y las CPS correspondientes. http://timestamp.apple.com/ts01 se utiliza en el ecosistema de firma de código de Apple y no debe considerarse un candidato genérico para Windows Authenticode.
Documentación oficial: Apple PKI
Servicios RFC 3161 públicos o de prueba
Los siguientes servicios ofrecen puntos finales RFC 3161 públicos, pero su ámbito de uso, cuota de llamadas o cadena de confianza no son adecuados como servicio genérico de sellado de tiempo para firma de código en producción. Antes de usarlos, debe verificar la cadena de certificados del sello de tiempo en el entorno de validación de destino.
| Proveedor | Dirección | Ámbito de aplicación | Limitaciones | Documentación oficial |
|---|---|---|---|---|
| MeSign | http://tsa.mesign.com | Firma de documentos, preservación de datos electrónicos y prueba del protocolo RFC 3161 | El servicio oficial de prueba gratuita está orientado al sellado de tiempo de documentos de Adobe, con un límite de 20 llamadas diarias por IP. La compatibilidad con la firma de código debe verificarse por separado. | MeSign TSA |
| FreeTSA | https://freetsa.org/tsr | Pruebas del protocolo RFC 3161, sellado de tiempo genérico de datos y código | Servicio público gratuito que utiliza su propia CA y certificado TSA; no debe asumirse que el sistema operativo de destino o el verificador de firma de código confíen en él de forma predeterminada. | FreeTSA |
Servicios que no deben listarse directamente como puntos finales públicos de sellado de tiempo para firma de código
Los siguientes tipos se diferencian de una "TSA pública de firma de código directamente configurable":
- Entrust: la página oficial actual describe un producto Timestamping Authority de implementación local basado en RFC 3161/RFC 5816, y no confirma en dicha página que
http://timestamp.entrust.net/TSS/RFC3161sha2TSsea un punto final público de sellado de tiempo para firma de código. - TSA comerciales de China continental: proveedores como GDCA, CFCA, Anxin CA, SmartCert y TrustAsia ofrecen productos de sellado de tiempo o herramientas de firma, pero sus páginas públicas de producto generalmente no proporcionan una URL de producción unificada que pueda invocarse de forma anónima. El punto final, el método de autenticación, el OID de política, los límites de velocidad y el SLA deben obtenerse mediante adquisición, contrato o soporte técnico del proveedor.
- Sigstore Timestamp Authority: se trata de una implementación de código abierto desplegable de TSA RFC 3161, no de un punto final público global fijo.
- Direcciones históricas de GlobalSign:
http://timestamp.globalsign.com/tsa/r6advanced1yhttp://rfc3161timestamp.globalsign.com/advancedno aparecen en la documentación actual de firma de código de GlobalSign; se debe utilizar la dirección actualmente publicadar45standard. - StartSSL:
http://tsa.startssl.com/rfc3161no tiene información oficial actual confirmable del servicio, por lo que no debe seguir utilizándose. - Dirección de ejemplo de nCipher:
http://dse200.ncipher.com/TSS/HttpTspServerse asemeja más a un sistema histórico de demostración o prueba, sin base de servicio público de producción actual. - Direcciones con origen y estrategia operativa poco claros:
https://ca.signfiles.com/tsa/get.aspx,http://services.globaltrustfinder.com/adss/tsayhttps://tsp.iaik.tugraz.at/tsp/TspRequestcarecen de suficiente documentación oficial actual del servicio, política de confianza o garantías de disponibilidad, por lo que no deben añadirse a la lista de candidatos de producción. - Otras TSA de redes de investigación: pueden utilizarse para pruebas de protocolo, pero no cuentan con suficiente material de garantía para la producción de firma de código, por lo que no se recomiendan como servicio predeterminado de producción.
Comprobaciones para la integración en producción
Antes de añadir una TSA a la lista predeterminada o a la cadena de respaldo de producción, confirme al menos lo siguiente:
- La documentación oficial del proveedor publica claramente el endpoint y los protocolos admitidos.
- Se utiliza el protocolo de sellado de tiempo correcto; no se pueden usar direcciones que solo admitan RFC 3161 para solicitudes de Authenticode.
- Se utiliza SHA-256 o un algoritmo de resumen de sellado de tiempo más seguro, y se confirma que la plataforma de destino es compatible con el algoritmo de firma y el tipo de clave de la TSA.
- Se comprueba la cadena completa de certificados de sellado de tiempo en el entorno de validación de destino de Windows, macOS u otros.
- Se confirma que la red de salida, el proxy, el firewall y el DNS pueden acceder de forma estable al endpoint.
- Se confirma el método de autenticación, los límites de velocidad, los términos del servicio, las restricciones regionales y el SLA.
- Se realiza la verificación de la firma con productos firmados reales; no se puede juzgar la disponibilidad de la TSA solo mediante el acceso por navegador o el código de estado HTTP.