Explicación de los códigos de motivo de CRL: Revocación de certificados en PKI

La revocación de certificados es uno de los aspectos más importantes, aunque a menudo ignorados, de la infraestructura de clave pública . Cuando un certificado deja de ser confiable antes de su fecha de vencimiento, la Autoridad de Certificación (CA) emisora ​​lo revoca y publica dicho estado mediante mecanismos como las Listas de Revocación de Certificados (CRL) o el Protocolo de Estado de Certificados en Línea (OCSP).

El estado de revocación indica a las partes que confían en un certificado que ya no se debe confiar en él. Un código de motivo de revocación añade contexto al explicar el porqué, y esa información se incluye en la extensión CRLReason definida en la RFC 5280.

Comprender los códigos de motivo de CRL ayuda a los administradores de PKI, equipos de seguridad, auditores y equipos de cumplimiento a diferenciar entre un evento rutinario del ciclo de vida de un certificado y un incidente de seguridad real. Este blog explica qué son estos códigos, los valores que define la RFC 5280, en qué se diferencian de los ReasonFlags, cómo los limita la política pública de TLS y las prácticas que mantienen la utilidad de los datos de revocación.

¿Qué son los códigos de motivo CRL?

Un código de motivo de CRL es un valor estandarizado que se puede incluir en una entrada CRL individual para indicar por qué se revocó un certificado. El RFC 5280 define CRLReason como una extensión opcional de la entrada CRL asociada a un certificado revocado, de modo que, en lugar de simplemente marcar un certificado como no válido, la CA puede registrar el motivo.

Esta distinción es crucial desde el punto de vista operativo. Un certificado revocado por haber sido reemplazado por uno más reciente requiere una respuesta muy diferente a la de un certificado revocado por haber sido comprometida su clave privada. Dado que los códigos siguen un estándar común, las plataformas de gestión del ciclo de vida de los certificados , los sistemas de monitorización y los flujos de trabajo de seguridad pueden procesar los eventos de revocación de forma coherente en distintos entornos PKI.

Códigos de motivo CRL definidos en RFC 5280

El RFC 5280 define los valores CRLReason como una enumeración ASN.1. El código numérico es importante porque es el que aparece en la entrada CRL del certificado.

Código	Razón	Significado
0	sin especificar	No se da ninguna razón específica.
1	claveCompromiso	Se sabe o se sospecha que la clave privada del certificado está comprometida.
2	cACompromiso	Se sabe o se sospecha que la clave privada de la CA emisora ​​ha sido comprometida.
3	afiliaciónCambiado	El nombre o la información de afiliación del sujeto ha cambiado.
4	reemplazado	El certificado ha sido reemplazado por un certificado más reciente.
5	cese de la operación	El certificado ya no es necesario para su propósito original.
6	certificado	Suspensión temporal del certificado
8	eliminarDeCRL	Un certificado que anteriormente estaba en espera ya no se considera revocado; se utiliza únicamente en listas de revocación de certificados delta.
9	privilegio retirado	Se ha retirado un privilegio contenido en el certificado.
10	un compromiso	Se sabe o se sospecha que una clave de Autoridad de Atributo está comprometida.

El valor 7 está reservado intencionalmente y no se utiliza, por lo que la enumeración salta del 6 al 8. El desfase de uno en la asignación de estos códigos, al olvidar que el 7 no está presente, es una causa conocida de defectos en las listas de revocación de certificados (CRL) en entornos reales, por lo que conviene tener en cuenta esta discrepancia. No todas las autoridades de certificación (CA) utilizan todos los códigos, y los ecosistemas TLS públicos restringen los motivos permitidos, como se explica más adelante.

Por qué importan los motivos de revocación

El estado de revocación indica si un certificado sigue siendo fiable. Los motivos de revocación explican por qué ya no lo es. La diferencia es similar a la que existe entre cambiar una tarjeta de crédito a punto de caducar por una nueva y denunciar el robo de una tarjeta: en ambos casos se cancela la tarjeta antigua, pero solo el segundo indica fraude y requiere una respuesta urgente.

Si un certificado se revoca por compromiso de clave, los equipos de seguridad suelen investigar la posible exposición de credenciales, rotar las claves afectadas y evaluar si los sistemas se vieron comprometidos . Por el contrario, la revocación de un certificado por haber sido reemplazado suele reflejar la gestión normal del ciclo de vida, como la sustitución de un certificado caducado por uno renovado. Este contexto mejora la respuesta a incidentes, la elaboración de informes de cumplimiento, las investigaciones de auditoría, la automatización del ciclo de vida y el análisis de la causa raíz.

Las organizaciones con grandes inventarios de certificados dependen de esta herramienta para priorizar la remediación y reducir el ruido operativo. En la práctica, los metadatos de revocación precisos son lo que permite medir y auditar un programa de ciclo de vida de certificados.

CRLReason y ReasonFlags no son lo mismo

Una de las ideas erróneas más comunes sobre PKI es tratar CRLReason y ReasonFlags como si fueran lo mismo. No lo son.

CRLReason es el motivo de revocación vinculado a una entrada de certificado revocado específica en una CRL, y explica por qué se revocó ese certificado en particular. ReasonFlags es una cadena de bits que se utiliza dentro de la extensión Puntos de distribución de CRL para indicar qué categorías de motivos de revocación abarca un punto de distribución en particular.

Componente	Propósito
CRLRasión	Explica por qué se revocó un certificado específico.
Indicadores de motivo	Indica qué motivos de revocación cubre un punto de distribución de CRL.

En la práctica, CRLReason describe el evento de revocación en sí, mientras que ReasonFlags ayuda a las aplicaciones y sistemas que utilizan certificados a determinar dónde se puede encontrar la información de revocación pertinente. Esta distinción es importante al solucionar problemas de validación, diseñar una infraestructura de clave pública (PKI) o revisar un perfil de certificado. El papel más amplio de los emisores de confianza en esta cadena se aborda en la descripción general de la autoridad de certificación de Encryption Consulting.

Cómo afectan los códigos de motivo CRL a las operaciones TLS

Si bien el RFC 5280 define el conjunto completo de códigos, los ecosistemas TLS del mundo real añaden políticas adicionales. Las CA de confianza pública operan bajo los Requisitos Básicos y las políticas del programa raíz del navegador, y esas reglas limitan los motivos permitidos para los certificados de confianza pública.

Es importante conocer dos restricciones. Los Requisitos Básicos (BR §4.9.1.1) establecen que, para un certificado TLS, el CRLReason no debe estar sin especificar (0); si no se aplica ningún motivo específico, la CA omite por completo la extensión reasonCode. También prohíben certificateHold (6) para certificados TLS, y varios códigos, como cACompromise, removeFromCRL y aACompromise, no se aplican en absoluto a los certificados TLS de entidad final. En el uso cotidiano, esto deja cinco códigos de motivo permitidos:

• La alerta keyCompromise indica un incidente de seguridad y, por lo general, desencadena una acción urgente.
• "Sustituido" indica un reemplazo rutinario del certificado.
• El mensaje "cessationOfOperation" aparece cuando se retira un servicio o una aplicación.
• El término "affiliationChanged" se aplica cuando cambia la propiedad o la autorización de la organización.
• privilegeWithdrawn es utilizado por la CA cuando hay evidencia de uso indebido del certificado o una violación sustancial del acuerdo de suscripción.

La revocación moderna combina listas de revocación de certificados (CRL), OCSP , supervisión de la transparencia de certificados y una duración cada vez menor de los certificados. En abril de 2025, el Foro CA/Browser adoptó la propuesta SC-081v3 , que reduce gradualmente la validez máxima de los certificados TLS de confianza pública de 398 días a 47 días para el 15 de marzo de 2029. El primer límite de 200 días entró en vigor el 15 de marzo de 2026, con una reducción adicional a 100 días el 15 de marzo de 2027 y un límite final de 47 días el 15 de marzo de 2029.

Durante el mismo período, el plazo para reutilizar los datos de validación de dominio se reduce a 10 días. En conjunto, estos cambios hacen que la gestión automatizada del ciclo de vida de los certificados sea esencial, en lugar de opcional. El manejo de la revocación por parte del navegador varía, pero la información precisa sobre la revocación sigue siendo fundamental para la confianza en la infraestructura de clave pública (PKI), y depende de la misma disciplina aplicada a los certificados TLS a lo largo de su vida útil.

Errores comunes y desafíos del mundo real

Muchas organizaciones utilizan por defecto la opción "no especificado" para casi todas las revocaciones. Si bien esto es técnicamente válido para la infraestructura de clave pública (PKI) privada, elimina el contexto que hace que las investigaciones, los informes y la automatización sean eficaces, y para el protocolo TLS público ni siquiera está permitido.

Otro problema frecuente es la mala interpretación de certificateHold. Fue diseñado para la suspensión temporal, no para la revocación permanente, y aunque el RFC 5280 lo define, es poco común en entornos modernos y no está permitido para TLS público. Los equipos también confunden CRLReason con ReasonFlags, lo que lleva a suposiciones erróneas sobre cómo se distribuye y procesa la información de revocación.

En entornos regulados, el uso inconsistente de los códigos de motivo genera problemas de auditoría, ya que un investigador no puede determinar si un certificado fue revocado debido a un incidente de seguridad o a un cambio administrativo rutinario.

Mejores prácticas de seguridad

La revocación debe considerarse una parte fundamental de la gestión del ciclo de vida de los certificados, no un simple requisito de cumplimiento. Al revocar certificados, algunos hábitos contribuyen a que los datos sean fiables y útiles.

• Utilice el motivo más preciso disponible y, para TLS público, omita el reasonCode en lugar de dejar por defecto el valor no especificado.
• Documentar los procedimientos para las revocaciones relacionadas con vulneraciones de seguridad, de modo que keyCompromise se aplique de forma coherente y rápida.
• Mantenga registros de auditoría para cada acción de revocación.
• Proteja las claves de firma de CA con controles robustos, utilizando un FIPS 140-3 Validado de nivel 3 Módulo de seguridad de hardware Cuando sea apropiado, los servicios de gestión de claves y HSM de Encryption Consulting pueden ayudar a las organizaciones a seleccionar, implementar y operar la infraestructura HSM adecuada para su entorno PKI.
• Supervise la publicación de CRL y OCSP para que la información de revocación siga estando disponible para las partes que confían en ella.

Los metadatos de revocación precisos refuerzan tanto las operaciones de seguridad como los informes de cumplimiento, y ayudan a los equipos a responder con mayor rapidez cuando se produce un incidente relacionado con un certificado.

Cómo puede ayudar la consultoría de cifrado

Gestionar la revocación de certificados en una infraestructura extensa se vuelve más complejo cuando una organización opera con múltiples Autoridades de Certificación, tipos de certificados y dominios de confianza. Encryption Consulting ayuda a diseñar, implementar y administrar infraestructura de clave pública (PKI) escalable mediante sus Servicios de PKI Empresarial , que abarcan la gobernanza del ciclo de vida de los certificados, los flujos de trabajo de revocación, las revisiones de la arquitectura de las CA, la alineación con el cumplimiento normativo y las mejores prácticas operativas, de modo que la revocación respalde tanto los objetivos de seguridad como los de negocio.

Para las operaciones diarias, CertSecure Manager proporciona visibilidad centralizada de los inventarios de certificados, los eventos de vencimiento, los flujos de trabajo de renovación automatizados y el estado de los puntos finales de revocación (CRL y OCSP) en toda la empresa. A medida que los períodos de validez de confianza pública se reducen a 47 días, esta automatización marca la diferencia entre renovaciones rutinarias y interrupciones evitables.

Ya sea que el objetivo sea modernizar una infraestructura de clave pública (PKI) existente o construir una nueva arquitectura de confianza, Encryption Consulting puede ayudar a establecer procesos de revocación que sean seguros, auditables y operativamente eficientes.

Conclusión

Los códigos de motivo de CRL pueden parecer un detalle menor, pero explican por qué se revocan los certificados y cómo debe responder una organización. La distinción más importante a recordar es que CRLReason identifica el motivo de la revocación de un certificado específico, mientras que ReasonFlags identifica qué motivos de revocación cubre un punto de distribución de CRL. Confundir ambos conceptos puede provocar errores en el diseño, la resolución de problemas y las políticas de PKI.

A medida que las organizaciones automatizan más el ciclo de vida de los certificados, la información precisa sobre la revocación se vuelve más valiosa para las operaciones de seguridad, la auditoría, el cumplimiento normativo y la respuesta a incidentes. Si se utilizan correctamente, los códigos de motivo de la CRL transforman la revocación de una simple comprobación de estado en una parte fundamental de la gestión de la confianza. Un primer paso práctico consiste en estandarizar los códigos de motivo que utilizan sus equipos y confirmar que se ajustan tanto a la RFC 5280 como a las políticas que rigen sus certificados públicos.