Ciclo de vida y revocación de certificados

Todo certificado digital sigue un ciclo de vida definido, desde su creación hasta su retirada. Las etapas son: solicitud y registro (generar el par de claves y crear la CSR), emisión (la CA valida y firma), implementación (instalarlo en el servidor o dispositivo), uso (periodo operativo activo), renovación (antes de la caducidad) y revocación o caducidad (fin de su vida útil). Gestionar este ciclo de vida a gran escala, especialmente en empresas con miles de certificados, requiere automatización y herramientas de gestión del ciclo de vida de certificados (CLM), ya que el seguimiento manual inevitablemente provoca que caduquen certificados y se produzcan interrupciones del servicio.

El ciclo de vida del certificado comienza con una Certificate Signing Request (CSR). El solicitante genera un par de claves y, a continuación, crea una CSR que contiene la clave pública, la información del sujeto (CN, O, C) y está firmada con la clave privada (lo que demuestra la posesión de la clave privada sin revelarla). La CSR se envía a la CA, que valida la identidad del solicitante y, si la aprueba, firma el certificado. La clave privada nunca sale de la posesión del solicitante. La generación de la CSR es el paso crítico en el que se determina la fortaleza de la clave: se debe utilizar como mínimo RSA de 2048 bits o ECC de 256 bits.

Los certificados deben renovarse antes de que caduque su fecha notAfter. La práctica recomendada es iniciar el proceso de renovación al menos 30 días antes de la caducidad (muchas organizaciones establecen como objetivo entre 60 y 90 días). La renovación normalmente implica generar una nueva CSR y una nueva clave privada, enviarlas a la CA y sustituir el certificado y la clave antiguos en todos los servidores donde estén implementados. Let's Encrypt automatiza este proceso mediante el protocolo ACME: la herramienta certbot renueva automáticamente los certificados cuando les quedan menos de 30 días. Los certificados caducados provocan errores en el navegador que impiden a los usuarios acceder a los servicios.

La revocación de certificados es el proceso de invalidar un certificado antes de su fecha de caducidad programada. Entre los motivos de revocación se incluyen: que la clave privada se haya visto comprometida (el caso más urgente, que requiere una revocación inmediata), que el certificado se haya emitido por error (dominio u organización incorrectos), que la información del sujeto haya cambiado (la empresa cambió de nombre o el empleado se marchó) o que la propia CA se haya visto comprometida. La revocación es fundamental porque los navegadores y sistemas que no saben que un certificado ha sido revocado seguirán confiando en él, lo que concede al atacante que posea la clave privada robada la capacidad activa de realizar un ataque MITM hasta que el certificado caduque o se sepa que ha sido revocado.

Una Certificate Revocation List (CRL) es una lista firmada publicada por una CA que contiene los números de serie de todos los certificados que ha revocado y que aún no han caducado. Los clientes descargan la CRL, la almacenan en caché y comprueban si el número de serie de un certificado presentado aparece en la lista. Las CRL tienen limitaciones importantes: pueden ser muy grandes (las CA grandes tienen millones de certificados revocados), los clientes suelen almacenarlas en caché durante horas o días, lo que introduce retrasos, y descargar la CRL completa para cada conexión es ineficiente. Las CRL aún se utilizan, pero cada vez se complementan o sustituyen más por OCSP.

OCSP (Online Certificate Status Protocol) permite comprobar en tiempo real la revocación de certificados sin que los clientes tengan que descargar CRL completas. El cliente envía una consulta al respondedor OCSP de la CA con el número de serie del certificado. El respondedor contesta con una respuesta firmada que indica si el certificado está good, revoked (con la fecha y el motivo de la revocación) o unknown. OCSP es más rápido y puntual que CRL, pero cada conexión TLS requiere un recorrido HTTP adicional hasta el respondedor OCSP, lo que añade latencia. Las respuestas OCSP están firmadas por la CA para evitar manipulaciones.

OCSP Stapling resuelve el problema de latencia de las comprobaciones OCSP en tiempo real. En lugar de que el cliente consulte el respondedor OCSP de la CA durante cada handshake de TLS, el servidor obtiene previamente su propia respuesta OCSP de la CA y la «grapa» (la adjunta) al handshake de TLS. El cliente recibe directamente del servidor una respuesta OCSP reciente y firmada por la CA, sin necesidad de un recorrido de ida y vuelta adicional. El servidor actualiza periódicamente la respuesta OCSP grapada (normalmente cada hora). OCSP Stapling mejora la velocidad de conexión y reduce la carga de los respondedores OCSP de las CA, al tiempo que mantiene la comprobación de revocación.

OCSP Must-Staple es una extensión X.509 que indica a los navegadores que el servidor debe proporcionar una respuesta OCSP grapada. Sin ella, los navegadores realizan un «fallo permisivo» si la comprobación OCSP falla: permiten la conexión de todos modos, para evitar que las interrupciones de los respondedores OCSP bloqueen todas las conexiones TLS. Un atacante puede aprovechar este comportamiento de fallo permisivo bloqueando la solicitud OCSP del cliente, haciendo que parezca que el certificado sigue siendo válido incluso después de su revocación. OCSP Must-Staple lo evita al exigir una respuesta grapada válida; sin ella, el navegador rechaza la conexión. Su adopción sigue siendo limitada debido a la complejidad de implementación.

La revocación de certificados y Certificate Pinning abordan el mismo problema —confiar en certificados fraudulentos—, pero desde perspectivas diferentes. La revocación (CRL/OCSP) es un mecanismo reactivo: la CA invalida un certificado después de detectar un problema. Certificate Pinning es un mecanismo proactivo: la aplicación rechaza cualquier certificado excepto uno aprobado previamente. Certificate Pinning ofrece garantías más sólidas que la revocación porque funciona incluso si la CA no revoca el certificado con rapidez, pero introduce rigidez en la implementación. Para el examen Security+, conozca ambos mecanismos y comprenda que la revocación es el mecanismo PKI estándar, mientras que Certificate Pinning es una medida opcional de defensa en profundidad.

Cuando se revoca un certificado, la CA asigna un código de motivo de revocación que ayuda a los clientes y administradores a comprender la causa. Entre los códigos de motivo comunes definidos en RFC 5280 se incluyen: keyCompromise (la clave privada se vio comprometida), cACompromise (la CA emisora se vio comprometida), affiliationChanged (cambió la organización del sujeto), superseded (se emitió un certificado nuevo como reemplazo), cessationOfOperation (el dominio ya no está activo) y privilegeWithdrawn (se revocó la autorización). El código de motivo aparece tanto en las entradas de las CRL como en las respuestas OCSP, y proporciona contexto a los equipos de respuesta ante incidentes que investigan eventos de revocación.

El protocolo ACME (Automatic Certificate Management Environment), utilizado por Let's Encrypt, automatiza todo el ciclo de vida de los certificados. Los clientes ACME (como certbot) solicitan, renuevan e implementan certificados automáticamente, sin intervención humana. La CA utiliza desafíos de validación de dominio para confirmar la titularidad del dominio: el desafío HTTP-01 requiere colocar un archivo específico en una URL conocida; el desafío DNS-01 requiere crear un registro TXT de DNS. ACME ha transformado la gestión de certificados: los certificados de 90 días de Let's Encrypt ahora protegen una gran parte del tráfico HTTPS de Internet y se renuevan automáticamente.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que el ciclo de vida de los certificados va desde la generación de la CSR hasta la emisión, implementación y renovación o revocación; la CRL proporciona listas de revocación por lotes, mientras que OCSP proporciona el estado de cada certificado en tiempo real; OCSP Stapling elimina la latencia de OCSP en tiempo real; y ACME (Let's Encrypt) automatiza todo el ciclo de renovación. A continuación, exploraremos los casos de uso de PKI.