Certificados TLS de servidor
Tráfico web seguro a gran escala
Inventario de certificados
Descubrir y rastrear todos los certificados
Certificados DevOps
Automatizar para pipelines CI/CD
Cifrado de correo electrónico
S/MIME para correo electrónico empresarial
Los certificados tienen fechas de expiración, pero a veces la confianza necesita ser revocada antes de que llegue esa fecha. La revocación de certificados es el mecanismo que permite a las organizaciones invalidar un certificado inmediatamente cuando algo sale mal, ya sea que una clave privada haya sido comprometida, un empleado se haya ido, o un dominio haya cambiado de propietario.
Cuando un Autoridad de Certificación emite un certificado digital, establece un período de validez: una fecha de inicio y una fecha de expiración. En circunstancias normales, el certificado es confiado durante ese período y rechazado después. ¿Qué ocurre cuando un certificado necesita ser invalidado antes de que expire?
Aquí es donde revocación de certificado entra en juego. La revocación es el proceso mediante el cual una CA declara que un certificado emitido previamente ya no debe ser confiado, aunque aún no haya expirado. Sin revocación, un certificado comprometido seguiría siendo válido hasta su expiración natural, lo que potencialmente le daría al atacante días, semanas o meses para suplantar un servidor legítimo, firmar código malicioso o interceptar comunicaciones cifradas.
El ecosistema PKI proporciona dos mecanismos principales para comunicar el estado de revocación a los clientes: Listas de Revocación de Certificados (CRL) y el Protocolo de Estado de Certificado en Línea (OCSP). Cada enfoque tiene fortalezas y compensaciones distintas, y comprenderlas es esencial para cualquiera que gestione certificados a gran escala.
No todos los problemas de certificado justifican la revocación, pero varios escenarios lo requieren absolutamente. El foro CA/Browser y la RFC 5280 definen razones estándar de revocación que ayudan a las organizaciones y a las partes dependientes a comprender por qué se retiró un certificado.
La razón más urgente. Si la clave privada asociada a un certificado ha sido expuesta (a través de una violación del servidor, copia de seguridad robada o repositorio filtrado), el certificado debe revocarse de inmediato. Cualquiera con la clave privada puede suplantar la identidad del certificado'.
Cuando un empleado abandona una organización, sus certificados de autenticación de cliente o S/MIME deben revocarse. De manera similar, cuando un dominio se vende o transfiere, los certificados TLS asociados deben invalidarse para que el nuevo propietario pueda obtener unos nuevos.
Si la clave de firma propia de una Autoridad de Certificación's está comprometida, cada certificado que ha emitido es potencialmente no confiable. La AC debe revocar los certificados afectados y, en casos graves, su propio certificado intermedio puede ser revocado por la AC raíz. La emisión incorrecta (un certificado emitido con información incorrecta o sin la validación adecuada) también requiere una revocación inmediata.
Cuando un certificado es reemplazado por uno nuevo (por ejemplo, después de una rotación de claves o una actualización de algoritmo), el certificado antiguo debe ser revocado para evitar confusión y reducir la superficie de ataque. Los servidores desmantelados y los servicios retirados también deben tener sus certificados revocados.
Una Lista de Revocación de Certificados es el mecanismo de revocación original definido en el estándar X.509. Una CRL es un archivo firmado, publicado por una CA, que contiene una lista de números de serie de todos los certificados que han sido revocados antes de su fecha de expiración. Cada entrada incluye el número de serie del certificado's, la fecha de revocación y, opcionalmente, un código de razón.
Las CRL se publican en URLs especificadas en el certificado's Puntos de Distribución de CRL extensión. Cuando un cliente (como un navegador o una aplicación) necesita verificar un certificado, descarga la CRL de esta URL y verifica si el número de serie del certificado's aparece en la lista. Si lo hace, el certificado es rechazado.
Las CRL se actualizan y firman periódicamente por la CA, típicamente según un horario fijo (cada pocas horas o una vez al día). Cada CRL incluye un nextUpdate sello de tiempo que indica a los clientes cuándo estará disponible una versión más reciente. Entre actualizaciones, los clientes almacenan la CRL en caché localmente para evitar descargas repetidas.
La principal limitación de las CRL es escalabilidad. Para una CA grande que ha revocado miles de certificados, el archivo CRL puede crecer a varios megabytes. Descargar y analizar un archivo grande solo para verificar un único certificado es ineficiente, especialmente en dispositivos móviles o en entornos de red limitados. Además, la brecha entre publicaciones de CRL crea una ventana donde un certificado revocado recientemente aún podría ser aceptado por clientes que usan una CRL en caché y desactualizada.
OCSP (definido en RFC 6960) fue desarrollado para abordar las limitaciones de las CRL. En lugar de descargar una lista completa de revocaciones, el cliente envía una solicitud ligera a un respondedor OCSP preguntando sobre el estado de un solo certificado. El respondedor responde con uno de tres estados: válido, revocado, o desconocido.
La URL del respondedor OCSP se especifica en el certificado Authority Information Access (AIA) extensión. El cliente incluye el número de serie del certificado y el identificador del emisor en la solicitud, y el respondedor devuelve una respuesta firmada que el cliente puede verificar. Dado que cada consulta se dirige a un solo certificado, la respuesta es pequeña (normalmente unos pocos cientos de bytes) y rápida de procesar.
OCSP ofrece varias ventajas sobre las CRL. Las respuestas son en tiempo real (o casi en tiempo real), los datos transferidos son mínimos, y los clientes no necesitan almacenar o analizar archivos grandes. Sin embargo, OCSP introduce sus propios desafíos. El cliente debe hacer una solicitud de red al respondedor OCSP por cada certificado que valida, lo que añade latencia al apretón de manos TLS. Si el respondedor es lento o inaccesible, los clientes enfrentan una decisión difícil: fallar abierto (aceptar el certificado sin verificación, lo cual es inseguro) o fallar cerrado (rechazar el certificado, lo que causa una interrupción). La mayoría de los navegadores eligen fallar abierto, lo que debilita la garantía de seguridad.
OCSP también plantea preocupaciones de privacidad. Porque el cliente envía el número de serie del certificado's al respondedor, la CA que opera el respondedor puede observar a qué sitios web o servicios se está conectando el usuario. Este es un problema importante para la privacidad del usuario, y fue una de las motivaciones detrás del atado de OCSP.
OCSP stapling (conocido formalmente como la extensión TLS Certificate Status Request, definida en RFC 6066) resuelve elegantemente los problemas de latencia y privacidad del OCSP estándar. En lugar de que el cliente consulte directamente al respondedor OCSP, el servidor obtiene su propia respuesta OCSP con anticipación y "fija" al handshake TLS.
El servidor web consulta periódicamente al respondedor OCSP el estado de su propio certificado. La respuesta OCSP firmada se almacena en caché localmente en el servidor. Esto ocurre en segundo plano y no afecta las solicitudes de los usuarios.
Cuando un cliente se conecta, el servidor incluye la respuesta OCSP en caché en el handshake TLS (específicamente, en el CertificateStatus mensaje). El cliente recibe el certificado y su estado de revocación en una única ida y vuelta.
El cliente verifica que la respuesta OCSP con sello esté firmada por la CA, que aún esté dentro de su ventana de validez, y confirma el estado del certificate's como "good." Debido a que la respuesta está firmada por la CA, el servidor no puede falsificar un estado favorable.
OCSP stapling elimina el viaje adicional de red al respondedor, elimina la preocupación de privacidad (la CA nunca ve la solicitud del cliente's), y reduce la carga en la infraestructura OCSP. Es compatible con todos los servidores web modernos (Apache, Nginx, IIS, Caddy) y se recomienda como una práctica recomendada para implementaciones TLS. La variante mejorada, OCSP Must-Staple (indicado por una extensión del certificado), indica a los clientes que requieran una respuesta con stapling y rechacen el certificado si no se proporciona, cerrando la brecha de fail-open.
Ambos mecanismos sirven al mismo propósito, pero lo abordan de manera diferente. Aquí hay una comparación lado a lado para ayudarle a entender cuándo es más apropiado cada uno.
CRL proporciona una lista completa de todos los certificados revocados. OCSP proporciona el estado de un certificado a la vez. Las CRL son por lotes; OCSP es solicitud/respuesta.
Las CRL pueden ser grandes (megabytes para CA ocupados), imponiendo una sobrecarga de descarga significativa. Las respuestas OCSP son diminutas (unos pocos cientos de bytes), lo que las hace mucho más eficientes para verificaciones individuales.
Las CRL se actualizan según un horario (horas o días), creando una ventana donde pueden servirse datos obsoletos. OCSP puede proporcionar estado casi en tiempo real, especialmente con períodos de validez de respuesta de corta duración.
Las CRL pueden almacenarse en caché y servirse desde CDNs, haciéndolas altamente disponibles. OCSP requiere un respondedor activo, lo que puede convertirse en un punto único de falla. OCSP stapling mitiga esto al trasladar la responsabilidad al servidor.
Las CRL preservan la privacidad del cliente porque la CA no sabe qué certificado está verificando el cliente. El OCSP estándar revela esta información al respondedor. OCSP stapling restaura la privacidad al eliminar la conexión directa cliente‑respondedor.
La mayoría de las CA públicas admiten ambos mecanismos. Los navegadores se han desplazado en gran medida hacia soluciones propietarias (como CRLSets en Chrome y CRLite en Firefox) que agregan datos de revocación para el rendimiento. El stapling OCSP sigue siendo el enfoque recomendado para los operadores de servidores.
Flujos de trabajo de revocación instantánea: Evertrust CLM le permite revocar cualquier certificado en su inventario con una sola acción, notificando automáticamente a la CA emisora y actualizando sus registros internos. Cuando se detecta una compromisión de clave, cada segundo cuenta.
Gestión de CRL y OCSP: Evertrust PKI opera como una Autoridad de Certificación completa con publicación de CRL incorporada y capacidades de respondedor OCSP. Las CRL se generan según el programa y las respuestas OCSP se sirven con intervalos de frescura configurables, asegurando que las partes confiantes siempre tengan acceso a datos de revocación actuales.
Monitoreo de revocación: Evertrust monitorea continuamente el estado de revocación de todos los certificados en su inventario, alertándolo si un certificado del que depende ha sido revocado por una CA externa. Esto es crítico para integridad de la cadena.
Reemplazo automatizado después de la revocación: Revocar un certificado es solo la mitad del trabajo. Evertrust automatiza la emisión y el despliegue de un certificado de reemplazo inmediatamente después de la revocación, evitando el interrupciones que a menudo siguen a procesos de revocación manual.
