2026-10-30 · RESEARCH · El equipo de Offensive Technology

¿Oculta un certificado wildcard tus subdominios?

¿Oculta un certificado wildcard tus subdominios? En su mayor parte, pero casi nadie lo utiliza realmente de esa forma. Analizamos el certificado activo actual de 660 dominios principales a través de los mismos registros públicos de Certificate Transparency que cualquiera puede consultar, y clasificamos lo que revela cada uno. El 63.8% enumera al menos un subdominio real por su nombre en entradas SAN en texto plano, sin ninguna protección por wildcard. Solo el 22.9% depende exclusivamente de un wildcard, ocultando la estructura de sus subdominios tal como la tecnología lo permite. Si se suma el 11.1% que hace ambas cosas a la vez, el 74.8% de los certificados actuales en los dominios principales revela un hostname específico, tengan o no también un wildcard. Un wildcard funciona realmente según lo diseñado. Casi nadie lo elige por esa razón.

Por qué esto es una decisión y no solo una opción por defecto

Los certificados wildcard y SAN (Subject Alternative Name) resuelven el mismo problema, cubrir más de un hostname con un solo certificado, pero de formas opuestas. Un wildcard coincide con un patrón: *.example.com es válido para cualquier nombre de un solo nivel bajo example.com, sin que ese nombre aparezca jamás en el propio certificado. Un certificado SAN, en cambio, lista los hostnames explícitamente; un certificado puede cubrir app.example.com, api.example.com, y admin.example.com al incluir los tres en el campo SAN. Ambos son estándar, ambos son emitidos por cualquier CA pública, y el subject del certificado no revela si el enfoque fue una decisión deliberada o un accidente de las herramientas utilizadas.

El accidente es el caso común. La emisión automatizada gratuita, la que utiliza casi cualquier despliegue moderno, suele solicitar un certificado para el hostname exacto con el que está configurado un servidor. Si levantas diez subdominios con diez solicitudes de certificados automatizadas independientes, obtienes diez certificados SAN, cada uno registrando su propio nombre, en lugar de un único wildcard que cubra los diez. Optar por un wildcard en su lugar es un paso adicional que la mayoría de los equipos nunca da, porque la vía por defecto ya genera un certificado funcional.

Los datos: qué eligen realmente 660 certificados actuales

Para cada uno de los 660 dominios principales con historial en Certificate Transparency, tomamos el certificado más reciente ya presente en nuestra caché local (cero peticiones nuevas a crt.sh en esta ejecución, reutilizando el conjunto de datos de tres publicaciones de investigación anteriores) y leímos sus campos Subject y SAN. Clasificamos cada certificado según lo que revela más allá del aburrido y universal par del dominio base y su www. dirección: una entrada wildcard sin nada más, un wildcard más hostnames explícitos, hostnames explícitos sin ningún wildcard, o ninguno de los dos.

Las barras ámbar revelan un hostname específico en algún lugar del certificado; las barras verde azulado no lo hacen. Solo la porción del 22.9% exclusivamente wildcard y la del 2.3% exclusivamente apex, un 25.2% de la muestra combinadas, mantienen los nombres de sus subdominios fuera del registro público. Los otros tres de cada cuatro dominios están, ahora mismo, exponiendo al menos un nombre de subdominio real a cualquiera que consulte Certificate Transparency.

Rara vez es solo un nombre

Una vez que un certificado revela algo, tiende a revelar más de un único hostname aislado. Entre los 494 certificados que nombraron al menos un subdominio específico, el caso típico lista solo uno o dos, pero la distribución tiene una cola larga: el certificado individual con mayor actividad de la muestra enumera 70 subdominios distintos, y 20 certificados (el 4.0% de todos los certificados que revelan datos) listan diez o más, con 9 de ellos listando 25 o más. Un certificado de ese tamaño no está ocultando nada, se parece más a un mapa de sitio público de la infraestructura de una organización, emitido en una sola petición y registrado en una sola entrada.

Vale la pena detenerse en esa última fila. Un certificado en el grupo "mixed" contiene 94 entradas wildcard distintas en una sola clave, junto con entradas SAN con nombre. Es casi con total certeza una plataforma o proveedor de SaaS que aplica cobertura wildcard a muchos subdominios regionales o de clientes a la vez. Es eficiente a nivel operativo. También significa que una sola clave privada, en caso de ser robada, es válida para cada subdominio bajo esos 94 patrones simultáneamente, presentes y futuros. El uso de wildcards cambia la privacidad de los subdominios por un riesgo diferente: cuánto radio de impacto se concentra detrás de una sola clave.

Por qué no todo el mundo utiliza simplemente un wildcard

Si un wildcard oculta más, ¿por qué solo el 22.9% de la muestra lo usa en exclusiva? Hay varias razones prácticas, ninguna de las cuales es un error por sí sola:

• La automatización opta por defecto por nombrar, no por usar wildcards. Herramientas como Certbot solicitan un certificado para el hostname al que el servidor ya responde. Obtener un wildcard en su lugar implica demostrar el control del dominio mediante un desafío DNS-01, un paso adicional con herramientas extra que la mayoría de los despliegues omite.
• Un wildcard solo cubre un nivel. *.example.com coincide con app.example.com pero no con a.app.example.com. Cualquier jerarquía real de segundo nivel requiere un segundo wildcard o entradas con nombre, lo que empuja de nuevo a las organizaciones hacia la enumeración incluso cuando ya cuentan con un wildcard.
• El radio de impacto del compromiso de claves es real. Una clave privada wildcard, una vez expuesta, suplanta a todos los subdominios que cubre al mismo tiempo. Una clave por host comprometida solo afectaba a ese host específico. Los equipos que gestionan subdominios sensibles y con propietarios independientes a veces eligen certificados con nombres explícitos específicamente para mantener reducido ese radio de impacto, aunque les cueste la privacidad de sus subdominios.
• Algunas auditorías exigen ver cobertura explícita. Algunos procesos de cumplimiento e inventario son más fáciles de ejecutar frente a un certificado que lista cada hostname cubierto por su nombre que frente a uno que declara cobertura a través de un patrón.

Cómo comprobar tu propio dominio

Esto lleva menos de un minuto y no requiere más que un navegador, porque lee el mismo registro público que leímos nosotros.

• Consulta crt.sh para ver tu certificado actual. Abre https://crt.sh/?q=yourdomain.com&output=json y revisa el campo name_value de la entrada más reciente, o verifica el certificado de tu servidor directamente con openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name".
• Cuenta lo que realmente revela. Una sola entrada *.yourdomain.com sin nada más es solo wildcard. Cualquier otra cosa, cualquier host con nombre más allá del dominio base y www., ya es pública a través de CT, tengas o no también un wildcard en otro lugar.
• Decide la compensación deliberadamente. Si la privacidad de los subdominios importa más que el radio de impacto del compromiso de claves para tu arquitectura, avanza hacia un wildcard y un flujo de emisión DNS-01. Si no es así, como mínimo trata cada SAN con nombre como permanentemente público y deja de confiar en un subdominio no publicado como forma de seguridad.

Lo que esto no demuestra

Límites honestos, porque una cifra sin sus salvedades es solo marketing.

• Analizamos el certificado más reciente por dominio, no su historial completo. Un dominio podría haber usado un wildcard durante años y solo recientemente haber añadido un SAN con nombre, o viceversa. Esta es una instantánea de la exposición actual, no un patrón histórico.
• Un SAN con nombre no es prueba de que el servicio detrás de él esté activo o sea accesible. Clasificamos el texto del hostname en un certificado, nada más. Algunos subdominios con nombre pueden apuntar a infraestructura que ya no existe.
• Es una muestra de 660 dominios de sitios grandes y consolidados. La clasificación de sitios principales de Tranco se inclina hacia organizaciones con suficiente infraestructura como para necesitar más de un hostname en primer lugar. Una población diferente alteraría la distribución exacta.
• Esto mide la exposición, no la explotabilidad. Conocer el nombre de un subdominio es reconocimiento. Lo que un atacante haga con ese nombre depende enteramente de lo que realmente se esté ejecutando detrás de él.

Preguntas frecuentes

¿Oculta los subdominios un certificado wildcard?

Parcialmente. Un wildcard para *.example.com registra solo la cadena del wildcard, no etiquetas específicas. Pero en nuestra muestra, el 63.8% de los certificados actuales nombra un subdominio real de todos modos, y solo el 22.9% depende puramente de un wildcard sin ningún host con nombre expuesto.

¿Pueden aparecer en los registros de Certificate Transparency los subdominios cubiertos por un wildcard?

La propia entrada wildcard aparece únicamente como el patrón, no como un nombre específico. Pero en el momento en que un certificado independiente nombra un host de forma explícita, ese nombre queda registrado por completo, incluso junto a un wildcard existente. El 11.1% de los certificados analizados aquí hace ambas cosas.

¿Cuál es la diferencia entre un certificado wildcard y uno SAN?

Un wildcard cubre un patrón, *.example.com, sin nombrar ningún subdominio. Un certificado SAN lista hostnames específicos de forma explícita. La emisión automatizada genera por defecto certificados SAN para el hostname exacto en el que opera un servidor, razón por la cual la enumeración, y no el uso de wildcards, es el caso habitual.

¿Es más seguro un certificado wildcard que listar cada subdominio explícitamente?

Para la privacidad del nombre de los subdominios, sí. Para el radio de impacto del compromiso de claves, no necesariamente: una clave wildcard robada es válida para todos los subdominios que cubre a la vez, mientras que una clave por host comprometida solo cubre ese host.

¿Qué ocurre si se compromete la clave privada de un certificado wildcard?

Un atacante puede suplantar cualquier subdominio bajo ese patrón hasta que el certificado sea revocado y reemitido en todos los lugares donde estaba desplegado. Un certificado en nuestra muestra contiene 94 entradas wildcard distintas en una sola clave, un amplio radio de impacto si esa clave llega a exponerse.

¿Cubre un wildcard subdominios de subdominios?

No. *.example.com coincide con a.example.com pero no con a.b.example.com. Un nombre de segundo nivel necesita su propio wildcard o una entrada SAN explícita, una de las razones por las que las organizaciones enumeran hostnames incluso cuando también cuentan con un wildcard.

¿Cómo utilizan los atacantes los registros de Certificate Transparency para enumerar subdominios a partir de listas SAN?

Cada certificado que emite una CA pública se registra según el RFC 6962 y se puede buscar de forma gratuita a través de crt.sh. Un certificado que enumera hostnames por su nombre entrega al atacante un mapa de subdominios listo para usar, sin necesidad de escaneos.

¿Deberías elegir wildcard o SAN por seguridad, no solo por conveniencia?

Si la privacidad de los nombres de subdominio importa, un wildcard es la opción por defecto más sólida, y la mayoría de las organizaciones en esta muestra no está tomando esa decisión. Si enumeras, trata cada SAN con nombre como permanentemente público y evalúa el balance del compromiso de claves antes de cambiar.

Lecturas relacionadas

• Cómo los registros de Certificate Transparency filtran subdominios internos Misma caché, la cuestión del contenido: qué categorías de hostname interno aparecen realmente cuando un certificado revela uno.
• ¿Cuánto tarda un certificado en aparecer en CT? Mismo ámbito de crt.sh, la cuestión de los tiempos en lugar de la cuestión de la exposición.
• ¿Ha entrado ya en vigor la regla de certificados de 200 días? Un tercer enfoque sobre la misma caché de 660 dominios: cuánto tiempo pueden vivir los certificados, no lo que revelan.