El candado que aparece junto a la dirección de una web es uno de los gestos de confianza más repetidos de internet. Indica que la conexión va cifrada y que el sitio es quien dice ser. Por eso inquieta lo que contó Google a principios de octubre de 2026: unos atacantes consiguieron certificados HTTPS auténticos, emitidos por autoridades legítimas, para varios dominios de Google y de otras grandes organizaciones. Para lograrlo no tuvieron que entrar en Google. Atacaron un punto más arriba en la cadena: los registros que gestionan tres dominios de país.

Según el equipo de seguridad de Chrome, los ataques se detectaron a finales de septiembre. Afectaron a los operadores externos que administran .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana). Ars Technica lo resumió así: comprometer tres registros de dominios bastó para llevarse certificados no autorizados.

Cómo se fabrica un certificado «falso» que es real

Para entender el ataque hay que saber cómo se consigue un certificado TLS, la pieza que hace funcionar el HTTPS. Lo emite una autoridad de certificación (CA), una entidad en la que confían los navegadores. Antes de emitirlo, la CA hace una validación de dominio: comprueba que quien lo pide controla de verdad ese dominio. Lo habitual es pedirle que publique un registro concreto en el DNS o que sirva un archivo en una dirección determinada.

El fallo está en que todo depende del DNS, la «guía telefónica» que traduce nombres en direcciones. Cada terminación de país tiene un registro que decide cuáles son los servidores DNS de referencia de todos los dominios que cuelgan de ella. Si alguien toma el control de ese registro, puede cambiar esos datos a su gusto. Eso es lo que pasó:

• Los atacantes comprometieron a los operadores de los tres ccTLD (dominios de nivel superior de código de país).
• Modificaron los registros DNS de referencia de algunos dominios bajo esas terminaciones.
• Al controlar el DNS, superaron sin problema las comprobaciones de las autoridades de certificación.
• Las CA emitieron certificados que, técnicamente, eran válidos.

Google insiste en que sus sistemas no se vieron comprometidos. Además, según recoge Help Net Security, la empresa no tiene motivos para pensar que las autoridades que emitieron los certificados hicieran algo mal: siguieron el procedimiento, pero el DNS en el que confiaban ya estaba en otras manos. Google no ha dicho qué dominios suyos se vieron afectados, ni qué autoridades emitieron los certificados, ni qué otras empresas fueron víctimas. Tampoco hay datos públicos sobre quién está detrás.

La respuesta: listas de bloqueo y registros públicos

Con un certificado así, un atacante situado en medio de la conexión podría hacerse pasar por un servicio legítimo sin que el navegador mostrara ningún aviso. Chrome reaccionó en dos frentes. Primero, bloqueó los certificados mediante CRLSets, listas de revocación que el navegador descarga solo y sin que el usuario tenga que hacer nada. Segundo, colaboró con las autoridades de certificación para revocarlos, de forma que dejen de valer también en otros navegadores.

La herramienta que permitió tirar del hilo fue Certificate Transparency (CT), un sistema de registros públicos en los que debe anotarse cada certificado emitido. Revisando esos registros, Google localizó certificados emitidos para dominios de otras organizaciones afectadas y también los bloqueó. Aun así, la propia empresa reconoce que no puede garantizar que haya encontrado todos.

«El bloqueo desde el navegador no debería ser la única línea de defensa», advierte Google, según Help Net Security.

Qué cambia para ti y cuál es la letra pequeña

Si usas Chrome, Google asegura que estás protegido automáticamente frente a los certificados que ha detectado. Las recomendaciones de verdad van para quienes administran dominios:

• Vigilar los registros de Certificate Transparency de toda su cartera, también los dominios aparcados o las versiones regionales con terminación de país, que son fáciles de olvidar.
• Publicar registros CAA restrictivos, que indican en el propio DNS qué autoridades pueden emitir certificados para un dominio, e incluso con qué cuenta.

Aquí está la letra pequeña: Google admite que los registros CAA no pueden impedir la emisión mientras dura un secuestro del DNS, porque el atacante también puede reescribirlos. Su utilidad llega después, cuando el propietario recupera el control. Por eso Google plantea cambios de fondo desde su programa de certificados raíz: acortar la validez de los certificados y limitar la reutilización de validaciones de dominio ya hechas. Si un certificado ilegítimo dura menos, también es menor el daño que puede causar.

Por qué importa

Este caso muestra que la seguridad de una web no depende solo de quien la gestiona, sino de toda la cadena de la que cuelga. Un registro de país mal protegido puede abrir la puerta a cualquier dominio con esa terminación, por grande que sea su propietario. La detección rápida fue posible porque los certificados son públicos y auditables, y esa transparencia es lo que permitió corregir el problema. Para cualquier empresa con dominios en varios países, la lección es directa: lo que no se vigila también se puede suplantar.