Atacantes tomaron el control de los operadores de tres dominios de país (.gh de Ghana, .sl de Sierra Leona y .as de Samoa Americana) y con eso consiguieron certificados HTTPS válidos para dominios de Google y de otras organizaciones. Google lo informó el 6 de octubre.
Al día siguiente, Let’s Encrypt anunció que desde el 10 de febrero de 2027 sus certificados van a durar 64 días en lugar de 90. Son dos noticias distintas que apuntan al mismo lugar: cuánto tiempo vale una prueba de que un dominio es tuyo.
Qué pasó con los certificados de Google
Una autoridad certificante (CA) emite un certificado después de verificar que quien lo pide controla el dominio. Esa verificación se llama validación de control de dominio (DCV) y casi siempre consiste en publicar un registro DNS o un archivo que la CA consulta.
Los atacantes no tocaron a Google: comprometieron a los terceros que operan esas tres terminaciones y modificaron los registros DNS autoritativos. Con el DNS en sus manos, la validación salía bien, porque para la CA el pedido venía de quien controlaba el dominio.
Google aclaró que sus sistemas no fueron comprometidos y que no tiene motivos para creer que las CA emisoras hayan hecho algo mal. No explicó cómo se vulneró a los operadores.
Según los relevamientos de prensa sobre los registros públicos, los compromisos ocurrieron el 22 (.gh), el 25 (.sl) y el 27 de septiembre (.as). Para nombres de Google y YouTube se contaron 12 certificados: 11 de Let’s Encrypt y uno de ZeroSSL. Otro relevamiento, que incluyó más marcas, llegó a 32.
Certificate Transparency: el registro que nadie puede borrar
Certificate Transparency (CT, «transparencia de certificados») es un sistema de registros públicos donde las CA tienen que anotar cada certificado que emiten. Los navegadores rechazan los certificados que no aparecen ahí, así que una emisión no puede quedar oculta.
Gracias a esos registros, Google encontró certificados para otras organizaciones afectadas («varias marcas globales líderes y servicios en línea muy usados», sin nombrarlas). Cualquiera puede consultarlos y recibir una alerta cuando se emite algo para sus dominios.
La respuesta y sus límites
Google tomó tres medidas:
- Bloqueó en Chrome los certificados de sus dominios mediante
CRLSets, la lista de revocación que Chrome distribuye por su cuenta. - Bloqueó también los certificados de las otras organizaciones detectadas por CT y las contactó cuando pudo.
- Coordinó con las CA la revocación, que protege también a otros navegadores y clientes.
Let’s Encrypt confirmó en su foro que los certificados para Google y YouTube se emitieron y fueron revocados. De acuerdo con los relevamientos, los de .gh y el de ZeroSSL cayeron el 26 de septiembre y el resto, el 1 de octubre.
Google advirtió que no puede garantizar haber identificado todos los dominios afectados y que sus bloqueos no protegen de forma confiable a quien usa otro navegador. Para los dueños de dominios recomienda:
- Monitorear CT para todo el portafolio, incluidos los dominios estacionados y los regionales de país.
- Publicar registros CAA restrictivos (un registro DNS que dice qué CA puede emitir para tu dominio), atados a una cuenta ACME y a un método de validación concreto.
- Si tenés dominios
.gh,.slo.as, revisar en CT las emisiones recientes.
CAA no frena una emisión mientras el atacante controla el DNS, pero sí impide que después reutilice una validación ya aprobada. Por eso Google vinculó el caso con la reducción de la validez de los certificados y del tiempo de reutilización de la DCV.
Let’s Encrypt pasa a 64 días
El anuncio del 7 de octubre fija este calendario:
- 14 de octubre de 2026: el entorno de pruebas (staging) empieza a emitir certificados de 64 días.
- 10 de febrero de 2027: todo certificado nuevo o renovado dura 64 días por defecto, y la reutilización de una validación baja de 30 a 10 días.
- 11 de mayo de 2027: vence el último certificado de 90 días.
- 16 de febrero de 2028: el perfil por defecto baja a 45 días y la reutilización de validaciones, a 7 horas.
Los certificados vigentes no se revocan, y los perfiles opcionales de 45 y 6 días siguen disponibles.
El movimiento acompaña la votación SC-081v3 del CA/Browser Forum (el organismo donde CA y navegadores acuerdan las reglas), aprobada en abril de 2025. La validez máxima de cualquier certificado público, pago o gratuito, quedó así:
- 200 días desde el 15 de marzo de 2026.
- 100 días desde el 15 de marzo de 2027.
- 47 días desde el 15 de marzo de 2029, con reutilización de la validación de dominio limitada a 10 días.
Qué hacer si renovás a mano o con scripts viejos
ACME y ARI
ACME es el protocolo con el que un programa pide, valida y renueva certificados sin intervención humana. ARI (ACME Renewal Information) es una extensión con la que la CA le avisa al cliente cuándo renovar.
Si tu cliente soporta ARI, no hay que tocar nada. Si renueva a un número fijo de días antes del vencimiento, Let’s Encrypt pide renovar a los dos tercios de la vida del certificado y buscar valores como 83, 80 o 60 en tareas de cron, scripts y procedimientos.
certbot
Desde la versión 4.1.0, certbot renew consulta ARI y, con Let’s Encrypt, renueva alrededor de los dos tercios de la vida útil.
IIS y Windows con win-acme
win-acme incorporó ARI en la rama 2.2.x, y las versiones 2.2.3 a 2.2.8 usaban un borrador de la especificación que Let’s Encrypt ya no acepta. Conviene actualizar y revisar que la tarea programada siga corriendo.
Azure App Service
El certificado administrado gratuito lo emite DigiCert y App Service lo renueva solo, mientras el dominio siga apuntando bien a la app. El riesgo está en los certificados subidos como .pfx: no tienen actualización automática del enlace, y con validez de 100 días habrá que reemplazarlos varias veces por año.
Azure Key Vault
Key Vault renueva de punta a punta los certificados de sus CA integradas (DigiCert y GlobalSign), y App Service sincroniza la versión nueva en hasta 24 horas. Con una CA no integrada, cada renovación implica generar un pedido de firma (CSR), enviarlo y fusionar la respuesta a mano.
¿Sabés cuántos certificados vencen en tu organización?
El caso de los dominios de país muestra que la confianza en HTTPS depende de eslabones que no controlás, y el calendario de la industria deja poco margen para renovar a mano.
¿Ya tienen monitoreo de Certificate Transparency para sus dominios y saben qué certificados siguen dependiendo de alguien que se acuerde de renovarlos? Te leemos en los comentarios.
Fuentes
- Google: Chrome’s Response to Recent ccTLD Registry Hijacks
- Let’s Encrypt Community: Chrome’s Response to Recent ccTLD Registry Hijacks
- Help Net Security: Hackers hijack three country-code domain registries
- The Hacker News: Attackers Hijack .gh, .sl, and .as Registries
- iTnews: Attackers hijack ccTLDs to fake certs for Google
- Let’s Encrypt: 64 day certs
- Let’s Encrypt: From 90 to 45
- CA/Browser Forum: Ballot SC-081v3
- Let’s Encrypt Community: Certbot 4.1.0 Release
- Microsoft Learn: Install a TLS/SSL certificate in Azure App Service
- Microsoft Learn: About Azure Key Vault certificate renewal
