2026-07-21 · INVESTIGACIÓN · El equipo de Offensive Technology

¿Cuántos de los principales dominios restringen quién puede emitir sus certificados?

Respuesta corta: Tomamos los 1.000 dominios con más tráfico de internet, resolvimos 994 de ellos y leímos el registro CAA que publica cada uno en DNS. Solo el 32.4% publica algún registro CAA. El otro 67.6% no impone ninguna restricción a nivel de DNS sobre qué autoridad de certificación puede emitir un certificado TLS para su nombre. Por lo tanto, cualquiera de las docenas de CA de confianza pública podría, en principio, ser engañada o comprometida para emitir un certificado válido para ellos, sin que nada publicado por el dominio lo impidiera. Entre la minoría que sí configura CAA, menos de la mitad (42.5%) solicita recibir avisos cuando una CA detecta una solicitud que infringe su directiva, que es la línea que convierte CAA de una valla silenciosa en una alarma. Todos los números provienen de búsquedas DNS públicas y pasivas que ejecutamos nosotros mismos contra una lista pública de sitios principales. No se contactó con ningún host ni se escaneó nada. Así es exactamente como lo medimos y lo que demuestra y no demuestra.

El hallazgo en un gráfico

Para cada dominio planteamos tres preguntas públicas. ¿Publica un registro CAA? Si es así, ¿define un contacto de notificación (iodef) para que una CA pueda alertarle sobre infracciones? ¿Y controla la emisión de comodines (wildcards) de forma independiente a la emisión ordinaria? Cada capa es más pequeña que la anterior:

Qué hace realmente un registro CAA

Todos los navegadores confían en docenas de autoridades de certificación y, por defecto, cualquiera de ellas puede emitir un certificado TLS válido para cualquier dominio. Eso resulta conveniente y también es el punto débil: si se engaña a una sola CA mediante una comprobación de validación de dominio defectuosa, o se la coacciona o compromete, puede emitir un certificado para un nombre que no es su cliente y el navegador lo aceptará. La emisión indebida de certificados no es algo hipotético; es la razón por la que la industria creó defensas en capas en torno a la emisión.

CAA (RFC 8659, que reemplazó al anterior RFC 6844) es la mitad a nivel de DNS de esa defensa. Un dominio publica un registro corto que dice, en la práctica, "solo estas CA pueden emitir para mí". Desde que un CA/Browser Forum acuerdo entró en vigor el 8 de septiembre de 2017, todas las CA de confianza pública están obligadas a consultar ese registro en el momento de la emisión y denegar cualquier certificado que el registro no autorice. Es un control poco habitual que resulta gratuito de configurar y que la otra parte aplica activamente.

Un conjunto de registros CAA consta de varias partes móviles:

• issue indica una CA que puede emitir certificados ordinarios, por ejemplo 0 issue "letsencrypt.org". Un issue ";" con un punto y coma significa que ninguna CA puede emitir certificados.
• issuewild rige los certificados comodín (*.example.com) por separado, lo cual es importante porque un solo certificado comodín supone un radio de impacto mayor que un solo nombre de host.
• iodef especifica una URL o buzón de correo donde una CA puede notificar una solicitud que infrinja la directiva. Marca la diferencia entre bloquear en silencio una solicitud maliciosa y enterarse de que se intentó realizar.

Dos tercios de los dominios más frecuentados no definen nada

El dato más destacado es la ausencia. De los 994 dominios que resolvieron, 672 (67.6%) no publican ningún registro CAA. Para esos dominios, el DNS no dice nada sobre quién puede emitir sus certificados, por lo que la respuesta es: cualquiera en el almacén de confianza pública. Esto no es una brecha ni representa, por sí solo, una vulnerabilidad. Es una oportunidad perdida para reducir la superficie de ataque frente a un tipo de ataque, utilizando un registro que cuesta una sola línea y cero dinero.

Entre los 322 dominios que sí publican CAA, la mayoría no depende de un solo proveedor: dos tercios (66.5%) autorizan a más de una autoridad de certificación, con una mediana de tres. Eso es normal y sensato para una organización que utiliza diferentes CA para distintos sistemas, un proveedor de PKI interna aquí, una CA pública para el sitio de marketing allá. Lo que llama la atención es la brecha en las notificaciones. Solo el 42.5% de los editores configura un contacto iodef, por lo que la mayoría ha construido una valla pero ninguna alarma: una CA que reciba una solicitud que vulnere su directiva la rechazará, pero el propietario del dominio nunca sabrá que alguien lo intentó. Esto se conecta directamente con el mismo tema de nuestro estudio sobre la exposición de la autenticación de correo electrónico en estos dominios, donde el patrón fue el mismo: el registro básico se configura con más frecuencia que la opción que realmente activaría una alarma.

Cómo medimos esto

Cualquier escéptico debería poder replicar esto desde cero, así que aquí está todo el método sin ocultar nada.

• La población. Utilizamos la lista Tranco (lista N29KW, generada el 20 de julio de 2026), un ranking de sitios principales orientado a la investigación que promedia varios proveedores a lo largo de 30 días para evitar manipulaciones cotidianas. Es pública, versionada y citable de forma permanente, lo que importa más para la reproducibilidad que la lista de cualquier proveedor individual. Consulta tranco-list.eu y el artículo académico subyacente de NDSS 2019.
• La muestra. Los 1.000 dominios principales de esa lista. 994 resolvieron a servidores de nombres activos; 6 no lo hicieron y fueron descartados, por lo que el denominador es 994.
• Las consultas. Para cada dominio, una consulta dig CAA <domain> contra resolvedores recursivos públicos, además de una consulta NS como comprobación de disponibilidad. Analizamos la respuesta en busca de las etiquetas issue, issuewild e iodef y las leímos en el apex del dominio, que es la métrica de adopción convencional y el registro que una CA consulta para el dominio registrado.
• Lo que no hicimos. Nunca solicitamos un certificado, ni nos conectamos a un servidor web, ni escaneamos nada. Leer un registro DNS público es una consulta, no un escaneo ni un sondeo. Es el mismo límite entre una verificación y un delito que rige cada auditoría que realizamos.
• Lo que conservamos. Solo conteos agregados y porcentajes. Los resultados por dominio permanecieron en memoria durante la ejecución y nunca se escribieron en disco. No se nombra ningún dominio. Solo registramos si existía una etiqueta iodef, nunca su valor de contacto, y no recopilamos datos personales; los dominios y sus registros DNS no son datos personales.

Una mirada neutral a quién resulta autorizado

Vale la pena mostrar un dato agregado porque describe a las autoridades de certificación, no a los sitios que medimos, y no nombra ningún dominio. Entre los 322 dominios que publican CAA, estos emisores aparecieron con mayor frecuencia en las listas autorizadas. Léelo como un mapa de popularidad de CA de confianza, no como una tabla de clasificación de la seguridad de nadie:

Lo que esto no demuestra

Límites honestos, porque un número sin sus matices no es más que marketing.

• Es una foto fija. El DNS cambia a diario. Estas cifras corresponden al 20 de julio de 2026, no a una tendencia. Un dominio que hoy no tiene CAA podría añadirlo la semana que viene.
• La ausencia de CAA no es una vulnerabilidad. Es un control que no se activó. Muchas organizaciones bien gestionadas prescinden de CAA y confían en otras capas. Estamos midiendo la adopción de una medida de bastionado, no contando fallos de seguridad.
• CAA no es un muro. Solo vincula a las CA que lo respetan, no revoca certificados ya emitidos y no sirve de nada si se compromete una CA que sí habías autorizado. Reduce el conjunto de emisores que pueden actuar e iodef notifica los intentos. Detectar una emisión no prevista a posteriori es tarea de la monitorización de Certificate Transparency, que se combina de forma natural con CAA.
• Solo apex. Leímos el registro CAA en el apex de cada dominio registrado. Debido a que CAA se evalúa subiendo por el árbol DNS, un subdominio puede heredar o reemplazar esto; no enumeramos subdominios, ni lo haríamos, porque eso empieza a parecerse a mapear la infraestructura privada de alguien en lugar de leer un solo registro público.
• La parte superior de la lista es heterogénea. Los dominios más frecuentados incluyen CDN e infraestructuras cuyas prácticas de certificados difieren de las de una empresa típica. La población consta de "los nombres con más tráfico", no de "empresas como la suya", por lo que debe interpretar los porcentajes como un panorama general y no como un referente de su propio riesgo.

Por qué le importa a un atacante y por qué debería importarle a usted

Un certificado falso pero válido es algo muy potente. Permite que un atacante que ya esté en posición de interceptar el tráfico, mediante una ruta de red secuestrada o un resolvedor envenenado, presente su dominio con un candado en el que el navegador confía, sin ninguna advertencia al visitante. La emisión indebida es rara precisamente porque las CA se auditan y CAA se aplica obligatoriamente, pero la palabra "rara" asume mucho peso cuando el coste de elevar el nivel es un único registro DNS. Publicar CAA elimina de la ecuación a cualquier CA que no utilice, y añadir un contacto iodef significa que si alguien intenta obtener un certificado a través de una CA que nunca autorizó, se enterará directamente en lugar de saberlo por un cliente.

La solución no es glamurosa y es prácticamente gratuita: liste las CA que realmente utiliza, añada una entrada issuewild si emite comodines y configure un buzón iodef que revise. La parte difícil nunca es la edición en el DNS. Es conocer cada lugar desde el cual su organización obtiene certificados de forma legítima, para que la activación de CAA no interrumpa en silencio una renovación que había olvidado. Eso requiere criterio, y es el mismo criterio necesario para saber cuáles de sus superficies expuestas realmente importan y cuáles son solo ruido.

Autorización de certificados: respuestas rápidas

¿Qué es un registro CAA?

CAA (Certification Authority Authorization, RFC 8659) es un registro DNS que enumera qué autoridades de certificación pueden emitir certificados TLS para un dominio. Desde septiembre de 2017, el CA/Browser Forum exige a las CA de confianza pública que lo comprueben y denieguen cualquier emisión que el registro no autorice. La ausencia de un registro CAA implica la falta de restricciones: cualquier CA pública puede emitir.

¿Qué proporción de los dominios principales publica un registro CAA?

En nuestra comprobación de julio de 2026 sobre los 1.000 dominios con más tráfico (994 resueltos), solo el 32.4% publicaba un registro CAA; el 67.6% no publicaba ninguno. Entre los que publican, el 42.5% también define un contacto de notificación iodef y el 36% controla la emisión de comodines por separado.

¿Impide un registro CAA cualquier emisión indebida de certificados?

No. Es defensa en profundidad: solo vincula a las CA que lo respetan, no revoca certificados ya emitidos y no evita que una CA autorizada resulte comprometida. Reduce quién puede emitir y, con iodef, notifica los intentos. Combínelo con la monitorización de Certificate Transparency.

¿Cómo compruebo y configuro mi propio registro CAA?

Consúltelo con dig CAA yourdomain.com. Para configurar uno, autorice únicamente las CA que utilice (por ejemplo 0 issue "letsencrypt.org"), añada una entrada issuewild si utiliza comodines y añada 0 iodef "mailto:[email protected]" para que una CA pueda notificar infracciones. Comprobar su propio registro es una consulta pasiva, por lo que es seguro y gratuito.

Lecturas relacionadas

• ¿Hasta qué punto están expuestos los principales dominios a la suplantación de correo electrónico?
• ¿Qué pueden ver realmente los atacantes sobre su empresa?
• Por qué la autorización va antes de cualquier prueba