Certificados (…5): Revocación · RCO · Tema 4

¿Cómo sabe el navegador que un certificado con firma válida de la CA ya no debe aceptarse? Siglas ↓

PUNTO DE PARTIDALa Validation Authority de la T52

En el Ejemplo gráfico la CA envía “Invalid information” a una Validation Authority (VA), y la tienda “enquires about public key certificate validity” antes de fiarse del certificado de User A.

Esa flecha es la revocación. En la web real la VA se materializa de varias formas:

un fichero firmado que la CA publica: CRL
un servidor al que se pregunta por un certificado concreto: respondedor OCSP
una lista que el propio navegador descarga de su fabricante: CRLSets / CRLite

La firma K−CA(HASH(datos)) de la T43 sigue siendo correcta en un certificado revocado. Por eso hace falta una comprobación aparte.

¿POR QUÉ?Motivos para revocar

K− comprometida

Han robado la clave privada del servidor. Quien la tenga puede hacerse pasar por él hasta que caduque el certificado.

Emisión indebida

La CA emitió a quien no debía. Puede pasar sin hackear a la CA, como en el caso de octubre de 2026.

Cambios administrativos

El dominio cambia de dueño, se cierra el servicio o el certificado incumple las normas de la CA/Browser Forum.

CASO REALCertificados no autorizados para Google

6 oct 2026 · Google Security Blog / Ars Technica

Los atacantes secuestraron los registros de tres ccTLD: .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana). Cambiaron los registros DNS autoritativos y las delegaciones de dominios concretos y así superaron la validación de control de dominio (DV) automática. Obtuvieron certificados para “varios dominios de Google” y para otras marcas grandes.

Ninguna CA fue hackeada. Todas cumplieron las reglas. El eslabón débil está en el modelo de confianza: quien controla el DNS de un dominio puede conseguir un certificado válido para él.

Respuesta: Chrome bloqueó los certificados identificados mediante CRLSets y Google consiguió que las CA revocasen los de sus dominios. Aun así, advierte de que puede haber certificados sin detectar y de que la intervención de Chrome no protege a usuarios de otros navegadores.

Precedente: DigiNotar (2011), una CA comprometida que emitió un certificado falso para google.com, entre más de 200 dominios. Se usó contra al menos 300.000 usuarios vinculados a Irán.

Pinning previeneEl cliente fija el hash SPKI de K+. El certificado falso trae otra clave y se rechaza. Se usa sobre todo en apps y clientes propios.

CT detectaTodo certificado de confianza aparece en logs públicos (SCT dentro del certificado). Monitorizarlos avisa de emisiones inesperadas.

Revocación corrigeRetira la confianza a un certificado ya emitido. Esta página trata de cómo llega ese aviso al navegador y de cuándo no llega.

ANIMACIÓNMecanismos paso a paso

Elige un mecanismo y avanza con Siguiente o pulsa Reproducir. Alice es el navegador y Mallory el atacante, como en las T35–36.

En el modo proyector: → Espacio o el mando avanzan · ← retrocede · 1–5 mecanismo · O opción · F pantalla completa · Esc salir

→ / Espacio: siguiente · ← anterior · 1–5 mecanismo · O opción · F pantalla completa

RESUMENComparativa

	CRL	OCSP	OCSP stapling	CRLSets / CRLite
Quién consulta	Cliente descarga la lista	Cliente pregunta a la CA	Servidor pregunta; cliente recibe la grapa	Fabricante del navegador; cliente consulta en local
Privacidad	Buena	La CA ve qué sitios visitas	Buena	Buena
Latencia	Descarga grande, cacheable	Un RTT extra por conexión	Ninguna extra	Ninguna
Frescura	Hasta nextUpdate (horas o días)	Alta	Validez de la grapa (horas o días)	Horas (CRLite: cada 12 h)
Si falla la consulta	Soft-fail habitual	Soft-fail habitual	Soft-fail salvo Must-Staple	No hay consulta en red que bloquear
Cobertura	Cualquier cliente	Cualquier cliente	Depende de la config. del servidor	Solo ese navegador (Chrome / Firefox)

TENDENCIASHacia dónde va la revocación

2011DigiNotar: certificado falso para google.com. La CA acaba retirada de todos los almacenes de confianza.
jul 2023 · CA/B Forum SC-063OCSP pasa a ser opcional para las CA y las CRL a ser obligatorias (en vigor en 2024).
2025 · Firefox 137 → 142CRLite activado para todos los usuarios de escritorio (Firefox 137). Firefox 142 deja de consultar OCSP para certificados DV.
30 ene → 7 may → 6 ago 2025 · Let’s EncryptDeja de admitir Must-Staple, quita la URL OCSP de sus certificados (pone la de la CRL) y apaga sus respondedores OCSP. Motivo principal: privacidad. En su pico atendía unos 340.000 millones de peticiones al mes.
15 mar 2026 · SC-081Validez máxima de un certificado TLS: 200 días. El periodo de reutilización de la validación de dominio (DCV) también baja a 200 días.
6 oct 2026Secuestro de .gh, .sl y .as. Chrome bloquea con CRLSets y Google recomienda CT + CAA restrictivos.
15 mar 2027 · SC-081Validez máxima: 100 días. DCV: 100 días.
15 mar 2029 · SC-081Validez máxima: 47 días. DCV: 10 días. Cuanto más corta es la vida de un certificado, menos importa una revocación que no llega.

Enlace con la T42: el “¡OJO!” del campo Validity es hoy una herramienta de seguridad. Caducar pronto es una forma de revocar sin depender de que el aviso llegue.

EN EL CURSODónde vuelve a aparecer

Seminario S1 · T31 y T39

El certificado de redescorporativas.es

El certificado wildcard de 2020 (T31) y el que se emitió en octubre de 2026 en el servidor del seminario, cert.redescorporativas.es (T39):

Campo	2020	2026
Emisor	Let’s Encrypt Authority X3	YE2 (jerarquía «Gen Y», ECDSA)
Validez	90 días	90 días (64 en 2027, 45 en 2028)
OCSP (AIA)	ocsp.int-x3.letsencrypt.org	no hay
CRL Distribution Points	no hay	ye2.c.lencr.org/70.crl
SCT (Certificate Transparency)	2	2
Uso (EKU)	servidor y cliente	solo servidor

Ejercicio: buscar redescorporativas.es en crt.sh y localizar los dos certificados en los logs de CT.

Seminario S1 · T14 y T24-27

El reto ACME es la validación DV

En el seminario (Plesk) se cambia temporalmente el registro A para que la CA vea el reto http-01. Es lo mismo que hicieron los atacantes de 2026 con el DNS de .gh, .sl y .as. Quien controla el DNS, consigue el certificado.

Defensa: un registro CAA que limite la CA, la cuenta ACME y el método de validación (RFC 8657):

redescorporativas.es. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/NNNN; validationmethods=dns-01"
redescorporativas.es. CAA 0 issuewild "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/NNNN"

Tema 6 · IPsec / IKE

VPN con CA propia: aquí sí hay hard-fail

En la fase de autenticación de IKE los certificados X.509 se validan igual que en la web. La diferencia es que en una VPN corporativa la CA es de la empresa: el administrador publica la CRL y puede exigir que se compruebe.

# strongSwan, swanctl.conf → connections.<vpn>.remote revocation = strict # sin estado de revocación válido, se rechaza

Revocar el certificado de un portátil robado corta su acceso a la VPN.

Tema 8 · TLS

Handshake y Heartbleed

El stapling viaja dentro del handshake: el cliente lo pide con la extensión status_request del ClientHello y en TLS 1.3 el servidor lo devuelve junto al certificado.

Heartbleed (2014) es el caso clásico de “K− comprometida”: cualquier servidor con OpenSSL vulnerable podía haber filtrado su clave privada. Una semana después solo unos 30.000 de los 500.000 certificados afectados se habían reemitido. Revocar a esa escala es lento.

LABORATORIOComprobarlo con openssl

1 · ¿Dónde publica la CA su información de revocación?

# Descargar el certificado del servidor openssl s_client -connect www.upv.es:443 -servername www.upv.es </dev/null 2>/dev/null \ | openssl x509 -out srv.pem # Buscar CRL Distribution Points y Authority Information Access (OCSP) openssl x509 -in srv.pem -noout -text | grep -A4 -E "CRL Distribution|Authority Information" openssl x509 -in srv.pem -noout -ocsp_uri

Prueba también con un sitio de Let’s Encrypt, por ejemplo cert.redescorporativas.es (el servidor del Seminario S1): verás la CRL pero ninguna URL OCSP.

2 · ¿Grapa el servidor la respuesta OCSP?

# -status pide stapling (extensión status_request) openssl s_client -connect www.upv.es:443 -servername www.upv.es -status </dev/null 2>/dev/null \ | grep -A12 "OCSP response" # "OCSP response: no response sent" → sin stapling # "Cert Status: good" → grapa válida

3 · Leer una CRL

# URL obtenida en el paso 1 curl -s -o ca.crl "http://URL-DE-LA-CRL" openssl crl -inform DER -in ca.crl -noout -text | head -30 # Last Update / Next Update → ventana de desactualización # Serial Number: ... → certificados revocados

4 · Pinning: hash SPKI de K+

openssl x509 -in srv.pem -pubkey -noout \ | openssl pkey -pubin -outform der \ | openssl dgst -sha256 -binary | base64 curl --pinnedpubkey "sha256//HASH_ANTERIOR=" https://www.upv.es/ -o /dev/null -w "%{http_code}\n" # Cambia una letra del hash: curl rechaza la conexión (error 90)

DEBATEPara clase

Seguridad frente a disponibilidad. Si el navegador aplicara hard-fail, una caída del respondedor OCSP de una CA dejaría inaccesibles millones de sitios. ¿Quién debería asumir ese riesgo?
Un control que falla abierto no es una barrera. ¿Qué otros mecanismos de red conocéis que fallen abiertos (firewall, NAC, 802.1X con VLAN de invitados…)?
¿Quién rota la clave y quién mantiene los clientes? El pinning protege, pero si el servidor cambia de K+ sin actualizar las apps, el servicio cae. Por eso se abandonó HPKP en navegadores.
El caso de 2026. Las CA cumplieron las normas. ¿Bastan CAA (con accounturi y validationmethods), registry lock, DNSSEC y MFA en el registrador? ¿Cuáles dependen del dueño del dominio y cuáles del registro del ccTLD?

TESTComprueba lo aprendido

SIGLASResumen de siglas y términos

Certificados y PKI

PKI: Public Key Infrastructure. Infraestructura de clave pública: CA, RA, VA, certificados y listas de revocación.
CA: Certification Authority. Autoridad de certificación. Firma certificados con su K− y los revoca.
RA: Registration Authority. Autoridad de registro. Verifica la identidad del solicitante (T52).
VA: Validation Authority. Autoridad de validación. Responde si un certificado sigue siendo válido (T52).
X.509: Norma ITU-T X.509. Formato estándar de los certificados de clave pública (T42).
K+ / K−: Clave pública / privada. K−CA(HASH(datos)) es la firma de la CA; se verifica con K+CA.
SAN: Subject Alternative Name. Extensión con los nombres de dominio del certificado. Es la que comprueban los navegadores.
SPKI: Subject Public Key Info. Campo con la clave pública. Su hash es lo que se fija en el pinning.
RSA: Rivest–Shamir–Adleman. Algoritmo de clave pública usado para cifrar y firmar.
PEM / DER: Privacy-Enhanced Mail / Distinguished Encoding Rules. Formatos de fichero: PEM es texto Base64, DER es binario (T46).

Revocación

CRL: Certificate Revocation List. Lista firmada por la CA con los números de serie revocados.
CRL DP: CRL Distribution Points. Extensión del certificado con la URL donde descargar la CRL.
OCSP: Online Certificate Status Protocol. Consulta a la CA por el estado de un certificado: good, revoked o unknown.
AIA: Authority Information Access. Extensión con la URL del respondedor OCSP y la del certificado de la CA.
Stapling: OCSP stapling. El servidor adjunta (“grapa”) en el handshake la respuesta OCSP firmada por la CA.
Must-Staple: TLS Feature: status_request. Extensión que obliga al cliente a rechazar la conexión si no llega la grapa.
CRLSets: Listas de Chrome. Selección de revocaciones que Google distribuye a Chrome con sus actualizaciones.
CRLite: Listas de Firefox. Todas las revocaciones comprimidas en filtros que Firefox descarga cada 12 h.
Soft-fail / hard-fail: Fallo abierto / cerrado. Si la comprobación falla: aceptar el certificado o rechazar la conexión.

Emisión y transparencia

DV: Domain Validation. Validación de dominio: la CA solo comprueba que controlas el dominio.
DCV: Domain Control Validation. La comprobación concreta del control del dominio. Su resultado se puede reutilizar un tiempo.
ACME: Automatic Certificate Management Environment. Protocolo de emisión automática (Let’s Encrypt, certbot). Retos http-01 y dns-01.
LE: Let’s Encrypt. CA gratuita y automatizada. Apagó su OCSP en 2025.
CAA: Certification Authority Authorization. Registro DNS que dice qué CA, cuenta ACME y método pueden emitir para el dominio.
CT: Certificate Transparency. Logs públicos donde se registran todos los certificados emitidos.
SCT: Signed Certificate Timestamp. Prueba firmada de que el certificado está en un log de CT. Va dentro del certificado.
CA/B Forum: CA/Browser Forum. Organismo de CA y navegadores que fija las reglas de emisión (Baseline Requirements).
SC-063 / SC-081: Ballots del CA/B Forum. SC-063: OCSP opcional y CRL obligatoria. SC-081: validez máxima de 200 → 100 → 47 días.
HPKP: HTTP Public Key Pinning. Pinning en cabecera HTTP para navegadores. Abandonado por riesgo de dejar sitios inaccesibles.

Red y protocolos

TLS: Transport Layer Security. Protocolo seguro sobre TCP (HTTPS). El certificado se envía en su handshake.
MITM: Man-in-the-Middle. Atacante en medio de la comunicación (Mallory, T36).
DNS: Domain Name System. Sistema de nombres. Quien lo controla puede superar la validación DV.
ccTLD: country-code Top-Level Domain. Dominio de primer nivel de un país: .es, .gh, .sl, .as.
DNSSEC: DNS Security Extensions. Firma las respuestas DNS para que no se puedan falsificar.
MFA: Multi-Factor Authentication. Autenticación con varios factores. Aquí, en la cuenta del registrador del dominio.
RTT: Round-Trip Time. Tiempo de ida y vuelta. OCSP añade uno por conexión.
HTTP / URL: Hypertext Transfer Protocol / Uniform Resource Locator. CRL y OCSP se consultan por HTTP en claro: la firma de la CA protege la integridad.
VPN / IPsec / IKE: Virtual Private Network / IP Security / Internet Key Exchange. Túnel cifrado; IKE negocia las claves y autentica con certificados (Tema 6).
RFC: Request for Comments. Documentos de estándares de Internet del IETF (p. ej. RFC 8657 para CAA).
NAC / VLAN: Network Access Control / Virtual LAN. Control de acceso a la red y redes locales virtuales (pregunta de debate).