Google bloquea certificados HTTPS no autorizados: qué revisar

Lo que se sabe

• Quién lo cuenta: el equipo Chrome Secure Web and Networking de Google, en el blog de seguridad de la empresa, el 6 de octubre de 2026. Dice que se enteró la semana anterior.
• Qué pasó: los atacantes comprometieron los tres dominios de país, que gestionan terceros, y modificaron registros DNS autoritativos. Así obtuvieron certificados HTTPS no autorizados para varios dominios de Google y de otras organizaciones, según Google. Estuvo en riesgo cualquier dominio terminado en .gh, .sl o .as. Los sistemas de Google no fueron comprometidos.
• Las autoridades de certificación: Google no las nombra y dice que no tiene motivos para creer que hicieran algo mal.
• Qué hizo Chrome: bloqueó los certificados de dominios de Google con CRLSets, su mecanismo para bloquear certificados, y trabajó con las autoridades para que los revocaran. Después, los registros públicos de Certificate Transparency mostraron más organizaciones afectadas, entre ellas marcas globales que Google no nombra, y Chrome bloqueó también esos certificados.
• Cuántos certificados: Google no da cifras. The Hacker News buscó el 7 de octubre en esos registros públicos y cuenta al menos 12 certificados para nombres de Google y YouTube bajo los tres dominios, registrados entre el 22 y el 27 de septiembre: 11 de Let's Encrypt y uno de ZeroSSL, todos ya revocados. Un miembro del equipo de Let's Encrypt confirmó el 7 de octubre, en su foro, que se emitieron y que están revocados.
• Lo que no se sabe: Google no dice quién está detrás, cómo entraron, si los tres dominios ya están asegurados ni si algún certificado llegó a usarse para suplantar una web.

Qué cambia y qué no

Quien navega con Chrome no tiene que hacer nada, según Google. Tampoco hay una acción urgente para un dominio .com o .pe: el incidente toca a tres dominios de país.

Cambia lo que conviene dar por supuesto: el candado del navegador se apoya en el DNS, y quien controla el DNS de un dominio puede pedir un certificado válido a su nombre. Y Google avisa de que no conviene confiar en que el navegador lo arregle: no garantiza haber encontrado todos los dominios afectados, y sus bloqueos no protegen bien a quien usa otro navegador.

Entre el primer certificado que lista The Hacker News (22 de septiembre) y la nota de Google (6 de octubre) pasaron 14 días, por la cuenta de este artículo.

Un matiz: el registro CAA no frena la emisión mientras dura un secuestro de DNS, según Google. Sirve después, porque las autoridades pueden reutilizar durante un tiempo una validación de dominio ya hecha y un CAA restrictivo, sobre todo si va atado a una cuenta concreta, impide que el atacante la aproveche. Ese plazo va a la baja: el CA/Browser Forum aprobó en abril de 2025 dejarlo en 10 días en marzo de 2029, y Let's Encrypt anunció en diciembre de 2025 que reducirá el suyo de 30 días a 7 horas para 2028.

Cómo saber si te afecta

Directamente, si tienes un dominio .gh, .sl o .as: Google pide revisar los certificados emitidos hace poco. Sus dos medidas valen para cualquier dominio, también .com y .pe. Seis pasos:

1. Mira qué certificados existen a nombre de tu dominio. Todo certificado en el que Chrome confía por defecto tiene que constar en registros públicos, según Google. La web de Certificate Transparency enlaza buscadores como crt.sh: escribe tu dominio y lee la lista.
2. Aprende a leerla. Ver muchos es normal: los certificados gratuitos duran pocos meses y se renuevan solos. Lo raro es un emisor que no es el de tu hosting ni el de tu CDN, o un subdominio que nadie creó.
3. Activa un aviso. Un monitor te escribe cuando se emite un certificado nuevo para tu dominio. Esa misma web lista 16 servicios, entre ellos Cert Spotter, Report URI y el aviso por correo de Cloudflare.
4. Mira si tienes registro CAA. Es un registro DNS que dice qué autoridades pueden emitir certificados para tu dominio. Si no existe, puede emitir cualquier autoridad pública que valide el control, explica la documentación de Let's Encrypt. Se consulta con una herramienta de DNS en línea, eligiendo el tipo CAA.
5. Antes de publicar uno, averigua quién emite tu certificado. Pulsa el candado de tu web y mira el emisor. Un CAA que no incluye a esa autoridad hará fallar la próxima renovación. Si usas un CDN con certificado propio, su autoridad también tiene que estar. Es una advertencia de este artículo.
6. Dónde se pone. En el editor de zona DNS del hosting, o de quien lleve tus DNS. Para Let's Encrypt lleva la etiqueta «issue» y el valor «letsencrypt.org», según su documentación. En hosting compartido, pregunta: «¿Qué autoridad emite mi certificado y puedo añadir un registro CAA?».

Atar el CAA a una cuenta es la versión que recomienda Google. Let's Encrypt lo admite con el parámetro «accounturi», pero en hosting compartido esa cuenta suele ser del proveedor.

Si encuentras un certificado que no pediste, denúncialo ante la autoridad que lo emitió: según The Hacker News, debe dar un primer informe en 24 horas.

Relacionado: La clave raíz del DNS cambia el 11 de octubre: qué revisar

Fuentes

• Google, «Chrome's Response to Recent ccTLD Registry Hijacks», 6 de octubre de 2026 (en inglés)
• Let's Encrypt, foro de la comunidad, respuesta de su equipo del 7 de octubre de 2026 (en inglés)
• Let's Encrypt, «Certification Authority Authorization (CAA)» (en inglés)
• Let's Encrypt, «Decreasing Certificate Lifetimes to 45 Days», 2 de diciembre de 2025 (en inglés)
• Certificate Transparency, lista de monitores (en inglés)
• CA/Browser Forum, votación SC-081v3, 11 de abril de 2025 (en inglés)
• The Hacker News, «Attackers Hijack .gh, .sl, and .as Registries to Obtain Certificates for Google Domains», 7 de octubre de 2026 (en inglés)

Actualizaciones: aquí se añadirá si Google, los gestores de los tres dominios de país o las autoridades de certificación publican cómo ocurrió, cuántos dominios fueron afectados o si algún certificado llegó a usarse.