Resumen

  • Geoff Huston revocó un certificado de prueba de Let’s Encrypt el 21 de abril de 2026 y confirmó su número de serie en la lista del emisor. A las 48 horas, las versiones de Firefox, Chrome y Safari que probó todavía lo aceptaban.
  • En su posterior presentación en APNIC 62, Firefox ya rechazaba el mismo certificado tras un par de semanas, mientras Chrome y Safari seguían aceptándolo en su prueba. El retraso entre anotar y hacer cumplir la revocación es el centro del caso.

El certificado constaba oficialmente como revocado. En el navegador, todavía se comportaba como un invitado con la acreditación puesta. Geoff Huston lo había emitido para una prueba con Let’s Encrypt y lo retiró cuatro horas después, el 21 de abril de 2026. Su número de serie apareció en la lista de revocación de la entidad emisora. El trámite estaba completo; faltaba ver quién lo había leído.

En el relato original de Huston para APNIC, Firefox 148.0.2, Chrome 147.0.7727.117 y Safari 25.4 permitieron la conexión 48 horas más tarde. Conviene conservar las versiones y el reloj: fue un certificado, un entorno de prueba y una fecha concreta. Aun así, la escena revela una grieta real entre publicar una orden y hacerla efectiva. La autoridad puede cambiar su registro; la decisión de aceptar la sesión TLS queda en el cliente.

La segunda observación cambia el reparto. En las diapositivas que llevó a APNIC 62, Huston dice que esperó un par de semanas. Firefox rechazaba entonces el certificado; Chrome y Safari todavía lo aceptaban en su ensayo. No hay que elegir una foto y descartar la otra. La diferencia entre las dos explica por qué «revocado» no es un interruptor instantáneo. Durante parte de la espera, el emisor y el navegador dicen cosas distintas sobre la misma clave.

¿Cómo viaja la mala noticia? Huston repasa las listas descargables, las consultas en línea, las respuestas anexadas por el servidor y los conjuntos de revocaciones distribuidos por los navegadores. Una lista grande pesa. Una consulta añade latencia y exige que el servicio conteste; también informa a la entidad emisora de cuándo se visita un sitio. Una respuesta anexada ahorra el viaje, pero un servidor que sabe que su certificado está revocado no se ofrecerá alegremente a enseñar la prueba. La arquitectura reparte entre actores distintos el coste de mantener el dato fresco.

Acortar los certificados parece una salida elegante hasta que se rompe una clave al principio de su vigencia. Huston compara 90, 45 y seis días: cada recorte reduce la ventana, ninguno elimina la necesidad de una revocación temprana. Un ciclo de horas impondría otra carga a la infraestructura de emisión. Por eso propone en su exposición llevar la información de la clave al DNS, protegerla mediante DNSSEC y usar TTL breves para forzar la actualización; incluso plantea adjuntar la cadena de validación a la conexión TLS. Es una propuesta de diseño, no una descripción del Web actual. Su pregunta queda flotando sobre cada candado del navegador: ¿cuántos minutos o días tiene permiso para envejecer una afirmación de confianza?