Certificados de firma de código

Introducción

La firma digital de código consiste en aplicar una firma digital a un programa informático destinado a su distribución por internet. Esta firma ayuda a verificar la autenticidad del software, es decir, que proviene del desarrollador original, y también a validar que el código no ha sido manipulado por un atacante durante su transmisión, por ejemplo, mediante la inserción de código malicioso o malware. La firma digital utilizada para la firma digital de código se encuentra en un certificado digital denominado certificado de firma digital.

Respuesta rápida: ¿Qué es un certificado de firma de código?

Un certificado de firma de código es un certificado digital X.509, emitido por una autoridad de certificación, que un editor de software utiliza para aplicar una firma digital al código antes de su distribución. Este certificado prueba el origen del software y confirma que el código no ha sido alterado desde su firma. Los certificados pueden ser autofirmados, de validación estándar o de validación extendida (EV), y se basan en el sellado de tiempo para mantener su validez tras la expiración del certificado y en la revocación para invalidar las claves comprometidas.

Resumen Ejecutivo

Los certificados de firma de código permiten a los desarrolladores de software demostrar la autenticidad e integridad ante usuarios finales, navegadores y sistemas operativos. Este artículo explica las diferencias entre los certificados de firma de código y los certificados SSL a través del campo Uso de clave X.509, las implementaciones específicas de cada proveedor (Authenticode, Apple, Java, Adobe AIR), los tres tipos de certificados (autofirmados, de validación estándar y de validación extendida), cómo el sellado de tiempo mantiene la confianza en el código firmado tras la expiración del certificado y cómo la revocación del certificado protege a los usuarios en caso de que se vea comprometida una clave privada. También incluye un glosario práctico y una lista de verificación para la gestión de certificados de firma de código a gran escala y su relación con la gestión del ciclo de vida de los certificados en general.

¿A quién deberían importarle los certificados de firma de código?

Los certificados de firma de código afectan a la ingeniería de lanzamiento de software, la arquitectura de seguridad, las operaciones de la plataforma y el cumplimiento normativo. A continuación, se describe lo que debe hacer cada rol.

Administradores de PKI

Realizar un seguimiento del tipo de validación y la fecha de caducidad de cada certificado de firma de código, y asegurar que se aplique una marca de tiempo a cada versión firmada para que los certificados caducados no dañen el software ya instalado.

Arquitectos de seguridad

Diseñar un sistema de protección de claves privadas para las claves de firma en función del nivel de validación del certificado, exigiendo almacenamiento respaldado por HSM para los certificados de firma de código EV y recomendándolo también para la validación estándar.

Equipos de plataforma

Integrar la firma de código en el proceso de compilación y lanzamiento para todas las plataformas en uso (Windows Authenticode, Apple, Java y Adobe AIR), de modo que ningún producto se envíe sin firmar.

Equipos de cumplimiento

Confirme que se utilizan certificados de firma de código EV donde sea necesario y que las claves privadas que los respaldan cumplen con la norma FIPS 140 de nivel 2 o una protección de hardware equivalente para fines de auditoría.

CISO

Considere la vulneración de una clave de firma de código como un incidente en la cadena de suministro, ya que los atacantes que la obtienen pueden firmar software malicioso que parecerá legítimo para todos los usuarios posteriores, y promueva procesos de revocación inmediatos precisamente para este escenario.

Por qué esto importa: Datos y plazos de entrega

Según la encuesta Trust Pulse de DigiCert (2 de julio de 2025), casi la mitad de las empresas sufrieron una interrupción relacionada con certificados el año pasado, y el 18.5 % de las organizaciones afectadas reportaron pérdidas superiores a 250 000 dólares, con un 37.5 % de esos incidentes vinculados específicamente a certificados caducados. Un certificado de firma de código caducado sin marca de tiempo puede provocar silenciosamente fallos en todas las compilaciones distribuidas previamente, lo que convierte este riesgo en un factor clave para la ingeniería de lanzamientos.

La propuesta SC-081v3 del Foro CA/Browser, aprobada el 11 de abril de 2025, reduce gradualmente la validez máxima de los certificados TLS públicos a 200 días a partir del 15 de marzo de 2026, a 100 días a partir del 15 de marzo de 2027 y a 47 días a partir del 15 de marzo de 2029. Si bien este calendario se centra en los certificados TLS/SSL en lugar de en los certificados de firma de código directamente, refleja la misma tendencia general del sector hacia períodos de validez más cortos y una mayor automatización de certificados que los programas de firma de código deberían anticipar.

El NIST finalizó sus estándares de criptografía post-cuántica, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA), el 13 de agosto de 2024. Los certificados de firma de código se basan en los mismos algoritmos de firma de clave pública que estos estándares reemplazarán eventualmente, por lo que incorporar agilidad criptográfica a la infraestructura de firma ahora evita una migración disruptiva más adelante.

Certificados de firma de código

Al igual que cualquier otro certificado digital, los certificados de firma de código se basan en el estándar X.509 y también deben ser firmados por un tercero de confianza, como una Autoridad de Certificación (CA) . Sin embargo, los certificados de firma de código no se pueden usar indistintamente con otros certificados, como los certificados SSL . La razón principal es que, según la especificación X.509, todo certificado digital contiene un campo de "Uso de clave", que indica el uso previsto del certificado y se completa al generarlo. La extensión "Uso de clave extendido" también puede contener información adicional sobre el uso del certificado. La especificación X.509 exige que un certificado no se utilice para un fin distinto al previsto. Por ejemplo, un certificado SSL tiene el campo de uso de clave configurado como "Firma digital", mientras que un certificado de firma de código lo tiene configurado como "Firma de código".

Si bien X.509 proporciona la especificación del formato del certificado, las implementaciones tecnológicas para generar certificados varían según el proveedor. Por ejemplo, Authenticode es una tecnología de firma de código de Microsoft que ayuda a los desarrolladores a firmar aplicaciones para el sistema operativo Windows. Los certificados Authenticode se utilizan para firmar archivos con extensiones como .exe, .dll, .ocx, .cab y .xpi. De igual forma, los certificados de firma de código de Apple se utilizan para firmar aplicaciones para iOS, los certificados de firma de código de Java se utilizan para firmar archivos .jar para Java Runtime Environment (JRE) y los certificados de Adobe AIR se utilizan para firmar archivos .air o .airi.

El proceso para obtener un certificado de firma de código es similar al de otros certificados digitales. Cualquier organización que desee publicar software para su distribución en internet solicita un certificado de firma de código a una Autoridad de Certificación (AC), proporcionando su clave pública y demás información de la organización. Cabe destacar que el par de claves pública-privada debe generarse por separado, al igual que con cualquier certificado digital. La AC valida al desarrollador (organización) que solicita el certificado, lo firma como prueba de validación y lo emite al desarrollador o editor del software. El certificado emitido por la AC incluye información como la identidad del editor, su clave pública, el período de validez, la firma digital de la AC y otros detalles.

Tipos de certificados de firma de código

Certificados autofirmados

Los desarrolladores de software pueden generar sus propios certificados autofirmados. Sin embargo, en estos casos, el proceso de verificación de firma durante la instalación del software mostrará una advertencia indicando que el software fue creado por un desarrollador desconocido. Los certificados autofirmados pueden utilizarse para pruebas y desarrollo local del software antes de su distribución pública. No obstante, no deben utilizarse para software de producción destinado a usuarios finales.

Para la distribución pública de software, los certificados emitidos por una CA son la mejor opción. Existen dos tipos de certificados de firma de código emitidos por una CA, según el tipo de validación.

Certificados de validación estándar

Este es el tipo predeterminado de certificado de firma de código e implica validaciones básicas del editor o desarrollador por parte de la CA. Para obtener un certificado de firma de código estándar, los editores de software deben cumplir con requisitos básicos como la longitud mínima de la clave, el período máximo de validez y el sellado de tiempo para las firmas digitales.

Certificados de validación extendida (EV)

Los certificados de firma de código EV implican los niveles más altos de validación y verificación del editor de software por parte de la CA y, por lo general, se emiten en un token de hardware para mayor seguridad. Para obtener un certificado EV, además de los requisitos básicos de los certificados estándar, los editores de software también deben cumplir con requisitos mucho más estrictos; por ejemplo, mantener las claves privadas en un Módulo de Seguridad de Hardware (HSM) que cumpla con la norma FIPS (Federal Information Processing Standards) 140 Nivel 2 o equivalente.

Caducidad del certificado y sellado de tiempo

Como cualquier certificado digital, los certificados de firma de código también caducan al final de su período de validez. Al caducar, la firma no se validará y el software podría dejar de instalarse o ejecutarse correctamente, aunque no exista ningún problema con el software en sí. Este problema se soluciona mediante el proceso de sellado de tiempo, que consiste en aplicar una marca de tiempo al código al firmar el archivo. Esto suele hacerse a través de un tercero de confianza, denominado Autoridad de Sellado de Tiempo (TSA), para comprobar la validez y autenticidad de la marca de tiempo. La presencia de una marca de tiempo garantiza que el software siga funcionando incluso después de que el certificado de firma de código haya caducado, lo que da tiempo al editor para renovarlo.

Revocación de certificado

Como hemos visto en artículos anteriores, la solidez de los sistemas de infraestructura de clave pública (PKI) depende de cómo se gestionan y protegen las claves privadas. Si la clave privada de un certificado digital se ve comprometida, la autoridad de certificación (CA) que lo emitió debe invalidarlo o revocarlo. La revocación de certificados es fundamental en caso de una brecha de seguridad: garantiza que los usuarios finales sean alertados de que el certificado ya no es fiable, lo que desalienta la descarga, instalación y uso posterior del software. La revocación de certificados se realiza incluyendo el certificado revocado en una lista de revocación de certificados (CRL) o actualizando su estado mediante el protocolo OCSP (Online Certificate Status Protocol). En un artículo posterior se abordarán con más detalle las CRL y el OCSP.

Glosario de certificados de firma de código

Definiciones rápidas y fáciles de extraer para los términos utilizados a lo largo de esta publicación.

Término	Definición
Certificado de firma de código	Un certificado digital X.509 se utiliza para aplicar una firma digital al software, lo que permite demostrar la identidad del editor y la integridad del código.
Campo de uso clave	Un campo X.509 que restringe un certificado a su propósito previsto, configurado como "Firma de código" para certificados de firma de código y "Firma digital" para certificados SSL.
código de autenticación	Tecnología de firma de código de Microsoft para firmar archivos ejecutables, DLL y archivos de instalación de Windows.
Autoridad de Sellado de Tiempo (TSA)	Un tercero de confianza que aplica una marca de tiempo verificable al código firmado, manteniendo la validez de la firma incluso después de que expire el certificado.
Certificado de Validación Extendida (EV)	Un certificado de firma de código que requiere la verificación más estricta por parte del editor, emitido normalmente en un token de hardware o HSM para una máxima protección de la clave.
Lista de revocación de certificados (CRL)	Una lista publicada por una CA que identifica los certificados que han sido revocados antes de su fecha de vencimiento prevista.

Lista de verificación para la emisión de certificados de firma de código

Utilice esta lista de verificación para relacionar los problemas comunes de firma de código con su impacto en el negocio y la responsabilidad de los mismos.

Problema	Impacto en el negocio	Acción sugerida	Propietario
El certificado de firma caduca sin sello de tiempo.	El software distribuido previamente no valida la firma y puede dejar de instalarse o ejecutarse.	Aplique un sello de tiempo a cada autorización firmada y supervise de forma proactiva la caducidad de los certificados.	Administrador de la infraestructura de clave pública (KPI)
Clave de firma almacenada sin protección de hardware.	Una clave comprometida permite a un atacante firmar un programa malicioso que aparenta provenir de un editor de confianza.	Trasladar las claves de firma detrás de un HSM, obligatorio para los certificados EV y recomendado para todos.	Arquitecto de seguridad
Certificado autofirmado utilizado en producción	Los usuarios finales ven una advertencia de "editor desconocido", lo que daña la confianza y la adopción.	Restringir los certificados autofirmados a las fases de desarrollo y pruebas; exigir certificados emitidos por una CA para las versiones finales.	Equipo de la plataforma
La clave comprometida no fue revocada de inmediato.	Los atacantes siguen firmando código malicioso que los usuarios finales consideran legítimo.	Establezca un proceso de incidentes para revocar inmediatamente los certificados comprometidos mediante CRL/OCSP.	CISO
El nivel de validación no coincide con los requisitos de distribución.	El software no cumple con los requisitos de confianza de la plataforma de terceros o del sistema operativo, lo que bloquea su distribución.	Confirme que los certificados EV se utilizan siempre que la plataforma o la política de cumplimiento lo requieran.	Equipo de cumplimiento

Gestión del ciclo de vida de los certificados y modernización de la infraestructura de clave pública (PKI)

Los certificados de firma de código requieren la misma disciplina de detección, emisión y renovación que cualquier otro componente de un programa de modernización de PKI . CertSecure Manager automatiza la detección, emisión y renovación de certificados, incluyendo la automatización del marcado de fecha y hora y el seguimiento de la caducidad, para que ningún certificado de firma caduque sin ser detectado.

Las organizaciones que emiten certificados a gran escala sin gestionar la infraestructura internamente pueden recurrir a PKI-as-a-Service para obtener una autoridad de certificación gestionada y alojada en la nube. Crear un inventario de identidades de máquinas y ejecutar el descubrimiento de certificados mediante CBOM Secure ayuda a identificar todos los certificados de firma que ya se utilizan en los procesos de compilación y lanzamiento. Además, completar una evaluación de preparación para PQC garantiza que la infraestructura de firma cuente con una ruta de migración hacia la agilidad criptográfica y los algoritmos de firma post-cuántica. El Centro de Excelencia PQC de Encryption Consulting ofrece orientación sobre la secuencia de dicha migración.

Para obtener más información sobre la importancia de la automatización de certificados en todo el entorno, consulte los artículos de nuestro Centro de Educación sobre las etapas del ciclo de vida de un certificado y cómo evitar interrupciones en el servicio . Para obtener contenido relacionado sobre la firma de código, consulte Firma de código: 5 principales beneficios , Firma de código: 5 mejores prácticas , Firma de código: posibles amenazas , Arquitectura de firma de código y Sello de tiempo en certificados de firma de código: importancia.

Medición del éxito y auditorías continuas

Realice un seguimiento del porcentaje de certificados de firma de código con la marca de tiempo habilitada, el porcentaje de claves de firma protegidas por la gestión de claves respaldada por hardware y la rapidez con la que se puede revocar un certificado comprometido una vez detectado. Audite periódicamente los inventarios de certificados de firma y los paneles de control de caducidad, trimestralmente para factores impulsados ​​por políticas como los requisitos de nivel de validación y las directrices del CA/Browser Forum, y continuamente para la caducidad de los certificados, de modo que un certificado de firma nunca caduque silenciosamente a mitad del ciclo de lanzamiento.

Preguntas frecuentes

¿Cuál es la principal conclusión sobre los certificados de firma de código?

Un certificado de firma de código demuestra la autenticidad e integridad del software mediante una firma digital X.509, y depende del sellado de tiempo para mantener la confianza después de su vencimiento y de la revocación para dejar de confiar en una clave comprometida.

¿Por qué es importante esto para los equipos de PKI empresariales?

Los equipos de PKI deben seleccionar el nivel de validación adecuado para cada caso de uso de firma y asegurarse de que cada versión tenga una marca de tiempo, ya que un certificado sin marcar que caduca puede provocar fallos en todo el software ya instalado.

¿Qué riesgos aumentan si este tema se aborda manualmente?

La gestión manual de los certificados de firma de código aumenta el riesgo de distribuir versiones sin firmar o sin sellar, almacenar claves de firma sin protección de hardware y pasar por alto la caducidad de un certificado, lo que provoca fallos en el software distribuido.

¿Qué equipos deberían asumir la responsabilidad de este cambio?

Los arquitectos de seguridad diseñan la protección de claves para las claves de firma, los equipos de plataforma integran la firma en los procesos de compilación, los administradores de PKI realizan un seguimiento de los tipos de validación de certificados y su caducidad, y los equipos de cumplimiento confirman el uso de EV cuando sea necesario.

¿Cómo se relaciona esto con la gestión del ciclo de vida de los certificados?

Los certificados de firma de código requieren la misma disciplina de detección, emisión, renovación y revocación que cualquier otro tipo de certificado; tratarlos como parte de un programa de gestión del ciclo de vida de los certificados evita que se pase por alto un certificado de firma.

¿Cómo deberían las organizaciones medir el éxito?

Realizar un seguimiento del porcentaje de certificados de firma con la marca de tiempo habilitada, el porcentaje de claves de firma con protección basada en hardware y la rapidez con la que se puede revocar un certificado comprometido una vez detectado.

¿Qué se debe auditar o supervisar periódicamente?

Realice auditorías periódicas del inventario de certificados de firma de código y del panel de control de caducidad, confirme que se aplica el sellado de tiempo a cada versión y verifique que las claves de firma permanezcan en el almacenamiento respaldado por hardware.

¿Cómo afecta este tema a las infraestructuras de clave pública (PKI) en la nube, híbridas o con múltiples autoridades de certificación (CA)?

Las organizaciones que firman código en múltiples plataformas y autoridades de certificación necesitan una visibilidad centralizada de cada certificado de firma en uso, ya que un certificado de una autoridad de certificación no controlada tiene la misma probabilidad de caducar sin que nadie se dé cuenta a mitad del ciclo de lanzamiento.

¿Qué errores comunes deben evitar los equipos?

Entre los errores más comunes se incluyen el envío de software de producción con un certificado autofirmado, la omisión del sellado de tiempo, el almacenamiento de claves de firma sin protección de hardware y el retraso en la revocación tras una vulneración de la clave.

¿Qué se debe renovar trimestralmente?

Revise los requisitos de nivel de validación en función de la plataforma actual y la política de cumplimiento, confirme que los certificados de firma aún cumplen con las directrices actuales del CA/Browser Forum y vuelva a verificar que los métodos de protección clave sigan siendo adecuados a medida que aumenta el volumen de firmas.