Extractor de SAN

Extrae Nombres Alternativos del Sujeto de certificados

Certificate (PEM Format)

About SANs

Subject Alternative Names (SANs) specify additional domains, IPs, or URIs that a certificate is valid for.

Extracted SANs

Paste a certificate to extract SANs

El SAN Extractor extrae todos los Subject Alternative Names de certificados X.509, proporcionando una lista limpia de cada nombre de host, dirección IP, dirección de correo electrónico y URI para los que el certificado es válido -- crítico porque los navegadores modernos usan los SANs exclusivamente para la validación de nombres de host, ignorando el campo Common Name. Pega uno o más certificados PEM y obtén un inventario completo de las identidades cubiertas.

Entendiendo los Subject Alternative Names

Los Subject Alternative Names son la forma en que los certificados modernos declaran qué identidades protegen. Cada vez que un navegador se conecta a un sitio HTTPS, verifica la extensión SAN del certificado para ver si el dominio en la barra de direcciones está listado. Si no lo está, la conexión falla con un error de discrepancia de nombre de host -- incluso si el dominio aparece en el campo más antiguo Common Name. Este ha sido el comportamiento en Chrome desde la versión 58 (2017), y todos los demás navegadores principales siguen la misma regla.

Para los administradores de sistemas, el impacto práctico es significativo. Necesitas saber exactamente qué dominios cubre un certificado antes de desplegarlo, antes de renovarlo, y cuando solucionas problemas de conexión. Un certificado para www.example.com podría también cubrir example.com, api.example.com y cdn.example.com, o podría cubrir solo el subdominio www. No puedes saberlo por el nombre del archivo del certificado o el Common Name solamente. La extensión SAN es la fuente autoritativa de verdad sobre lo que un certificado protege.

Este extractor obtiene cada entrada SAN de uno o más certificados y las presenta como una lista limpia y organizada. Para entrada de múltiples certificados (como una cadena o un paquete de certificados no relacionados), muestra qué SANs provienen de qué certificado. Esto facilita auditar la cobertura de certificados en toda tu infraestructura -- pega todos tus certificados, e inmediatamente ves cada dominio, dirección IP e identidad que está protegida.

Cómo extraer SANs de un certificado

  1. Pega uno o más certificados codificados en PEM (comenzando con -----BEGIN CERTIFICATE-----)
  2. La herramienta extrae y lista todos los Subject Alternative Names, organizados por tipo
  3. Revisa la lista de SAN para completitud y precisión
  4. Copia la salida como lista, patrón regex o fragmento de configuración

Ejemplo de extracción de SAN

De un certificado multi-dominio:

Certificate: CN=www.example.com

Subject Alternative Names:
  DNS: www.example.com
  DNS: example.com
  DNS: api.example.com
  DNS: *.staging.example.com
  IP:  203.0.113.50

Tipos de SAN

TipoDescripciónEjemplo
DNSNombres de dominio (más común)www.example.com
IPDirecciones IP para acceso directo por IP203.0.113.50
EmailDirecciones de correo electrónico (certificados S/MIME)[email protected]
URIIdentificadores uniformes de recursoshttps://example.com/auth

Salida de múltiples certificados

Cuando pegas un paquete con múltiples certificados, el extractor muestra qué SANs provienen de qué certificado:

CertificadoSubjectSANs
LeafCN=www.example.comwww.example.com, example.com, api.example.com
WildcardCN=*.internal.example.com*.internal.example.com, internal.example.com

Cuándo usar esta herramienta

  • Auditoría de dominios pre-renovación -- listar todos los dominios cubiertos por un certificado que expira para asegurar que la solicitud de renovación incluya cada SAN
  • Mapeo de cobertura de certificados -- documentar qué certificados protegen qué dominios en toda tu infraestructura
  • Verificación de cobertura wildcard -- confirmar que los certificados wildcard (*.example.com) cubren los subdominios esperados e identificar lo que no cubren (por ejemplo, sub.sub.example.com)
  • Planificación de migración -- extraer SANs de certificados existentes cuando migras a una nueva CA o consolidando certificados
  • Revisión de seguridad -- identificar dominios inesperados en un certificado que podrían indicar mala configuración o compromiso
  • Solución de problemas de discrepancia de nombre de host -- verificar que el dominio que causa un error TLS esté realmente listado en los SANs del certificado

Cómo funcionan los Subject Alternative Names

La extensión SAN (OID 2.5.29.17) fue introducida para superar las limitaciones del campo Common Name. Mientras que CN solo podía contener un solo nombre de host, la extensión SAN soporta múltiples nombres y diferentes tipos de nombres.

CN vs. SAN: Comportamiento actual de los navegadores

Desde 2017, los principales navegadores han deprecado el Common Name para la coincidencia de nombres de host:

  • Chrome 58+ -- ignora CN completamente; solo verifica SANs
  • Firefox 48+ -- ignora CN si hay SANs presentes
  • Safari -- sigue el mismo patrón

Esto significa que un certificado con CN=example.com pero sin entrada SAN DNS:example.com producirá un error de discrepancia de nombre de host en navegadores modernos. Siempre asegúrate de que cada dominio aparezca en la extensión SAN.

Alcance de certificados wildcard

Los SANs wildcard siguen reglas de coincidencia específicas:

SAN WildcardCoincide conNO coincide con
*.example.comwww.example.com, api.example.comexample.com, sub.www.example.com
*.sub.example.coma.sub.example.comsub.example.com, b.a.sub.example.com

Reglas clave:

  • Los wildcards solo coinciden con un nivel de subdominio
  • Los wildcards deben ser la etiqueta más a la izquierda (*.example.com, no www.*.com)
  • El dominio base (example.com) no coincide con *.example.com -- debe listarse como un SAN separado

Gestión de SANs en la práctica

El error más común relacionado con SANs es olvidar el dominio base. Si tus usuarios acceden tanto a www.example.com como a example.com, ambos deben aparecer como entradas SAN separadas. Un wildcard *.example.com cubre www.example.com pero no example.com en sí. Esto sorprende a muchos equipos cuando cambian de un certificado solo-wildcard a uno que esperan cubra el dominio apex. Siempre incluye tanto example.com como *.example.com (o www.example.com) como entradas separadas.

Para organizaciones con muchos subdominios, decidir entre un certificado wildcard y un certificado multi-SAN es una elección arquitectónica importante. Los certificados wildcard (*.example.com) son convenientes porque no necesitas listar cada subdominio, pero no pueden cubrir subdominios más profundos como api.v2.example.com o el dominio base. Los certificados multi-SAN listan cada dominio explícitamente, lo que te da control completo pero requiere actualizar el certificado cada vez que agregas un nuevo subdominio. Muchas organizaciones usan un wildcard para subdominios creados dinámicamente y un certificado multi-SAN separado para sus dominios principales.

Cuando audites la cobertura de certificados antes de renovaciones, extrae los SANs de tu certificado que expira y compáralos contra tus registros DNS. Es sorprendentemente común descubrir que un certificado fue emitido hace dos años con SANs que ya no coinciden con tu infraestructura actual. Se agregaron nuevos subdominios, se retiraron los antiguos, y el certificado nunca se actualizó. Este paso de auditoría previene la frustrante situación de desplegar un certificado renovado solo para descubrir que no cubre un subdominio que fue agregado después de que el certificado original fue emitido.

Preguntas frecuentes

¿Por qué mi certificado muestra dominios que no solicité? Algunas CAs agregan automáticamente tanto el dominio base como la variante www. Por ejemplo, solicitar un certificado para example.com puede resultar en SANs para tanto example.com como www.example.com. Además, los certificados multi-dominio (UCC/SAN) pueden incluir dominios de pedidos anteriores si fueron renovados en lugar de re-emitidos.

¿Cuántos SANs puede tener un solo certificado? No hay un límite estricto en el estándar X.509, pero existen límites prácticos. Let's Encrypt permite hasta 100 SANs por certificado. Las CAs comerciales típicamente soportan 25--250 SANs dependiendo del producto. Listas de SAN muy grandes aumentan el tamaño del certificado y el tiempo del handshake TLS.

¿Un certificado wildcard necesita el dominio base como SAN separado? Sí. Un SAN wildcard *.example.com no coincide con el dominio base example.com. Si necesitas que tanto *.example.com como example.com funcionen, ambos deben aparecer como entradas SAN separadas en el certificado.

¿Puede un certificado tener SANs tanto de DNS como de IP? Sí. Un solo certificado puede incluir tanto nombres DNS como direcciones IP como SANs. Esto es útil para servicios que son accedidos tanto por nombre de host como por dirección IP. Sin embargo, la mayoría de las CAs requieren validación adicional para SANs de direcciones IP, y Let's Encrypt actualmente no emite certificados con SANs de IP.

¿Por qué mi certificado muestra "hostname mismatch" aunque el CN coincide? Los navegadores modernos (Chrome 58+, Firefox 48+) ignoran el Common Name para la validación de nombre de host y solo verifican los Subject Alternative Names. Si tu dominio aparece en el CN pero no como una entrada SAN de DNS, los navegadores rechazarán el certificado. Asegúrate de que cada dominio esté listado como entrada SAN, no solo en el CN.

¿Cómo funcionan los SANs con subdominios de múltiples niveles? Un wildcard *.example.com solo coincide con un nivel de subdominio. Cubre www.example.com y api.example.com pero no cubre api.v2.example.com. Para subdominios de múltiples niveles, necesitas una entrada SAN explícita para cada uno o un wildcard separado como *.v2.example.com.

Herramientas relacionadas

IPparse•Herramientas gratuitas de cálculo de redes y subredes

© 2026 IPparse. All tools run locally in your browser.

100% Privacy-First • No Data Collected