Un «nombre alternativo del sujeto» (SAN) es una extensión del certificado X.509 que enumera todos los nombres de host, direcciones IP u otras identidades para las que es válido un certificado, más allá del único campo «nombre común». Los clientes TLS y los navegadores modernos validan la identidad de un certificado comparándola con sus entradas SAN, y no con el «nombre común», lo que hace que el SAN sea, en la práctica, obligatorio.
Puntos clave
- SAN enumera todos los nombres de host y direcciones IP que protege un certificado.
- Los clientes TLS validan la identidad comparándola con las entradas SAN, no con el nombre común.
- La RFC 5280 define SAN como una extensión estándar de los certificados X.509v3.
- Un único certificado puede contener numerosas entradas SAN de distintos tipos.
- Versa Los certificados VMS requieren una entrada SAN para cada FQDN o dirección IP utilizada.
En esta página: Por qué es importanteCómo funcionaTiposSAN y VersaPreguntas frecuentes
¿Por qué es importante la SAN?
Durante décadas, los clientes TLS comparaban la identidad de un certificado con un único campo: el nombre común (CN). Esto funcionaba cuando un servidor utilizaba un solo nombre de host, pero las infraestructuras modernas rara vez lo hacen: se distribuye la carga entre varios nombres, un dominio y sus subdominios, o un dispositivo al que se puede acceder mediante varias direcciones IP. El SAN resolvió este problema al permitir que un certificado declarara todas las identidades para las que es válido.
Este cambio también es importante para la seguridad. Los navegadores y las bibliotecas TLS dejaron de confiar en el «nombre común» (Common Name) para la verificación de identidad hace años: Chrome lo dejó en desuso en 2017, y los «Requisitos Básicos» del CA/Browser Forum exigen ahora el uso de SAN para cualquier certificado de confianza pública. Un certificado sin una entrada SAN coincidente falla la validación de inmediato, independientemente de su «nombre común». Emitir o solucionar problemas con certificados TLS hoy en día significa pensar en términos de SAN, no de CN.
¿Qué es una SAN?
El «Nombre alternativo del sujeto» (Subject Alternative Name) es una extensión de certificado definida en el RFC 5280, el estándar que regula los certificados de clave pública X.509v3. Se trata de una lista adjunta al certificado, y cada entrada tiene un tipo: un nombre DNS (el más habitual), una dirección IP, una dirección de correo electrónico o un URI, entre otros menos frecuentes. Un único certificado puede contener muchas entradas; normalmente, un dominio principal, varios subdominios y una o más direcciones IP.
Cuando un cliente TLS se conecta, comprueba si el nombre de host o la dirección IP a la que se ha conectado coincide con alguna de las entradas de la lista SAN; basta con que haya una coincidencia con cualquier entrada, y el nombre común se ignora incluso cuando está presente. Las autoridades de certificación validan la titularidad de cada entrada antes de emitir el certificado, por lo que añadir un nombre de host a un certificado ya existente implica reemitirlo con una lista actualizada, y no simplemente editar un campo del certificado existente.
Tipos de entradas SAN
La RFC 5280 define varios tipos de entradas SAN, aunque en la práctica predominan unos pocos. Nombre DNS (dNSName) Las entradas más habituales son aquellas que identifican un certificado mediante un nombre de dominio completo; un comodín al principio (*.example.com) abarca todo un nivel de subdominios en una sola entrada. Dirección IP (iPAddress) Las entradas identifican un certificado mediante una dirección IPv4 o IPv6 literal. Dirección de correo electrónico y URI Estas entradas aparecen en S/MIME y otros usos no relacionados con la web, siendo mucho menos habituales en las implementaciones de TLS.
A partir de estos tipos se derivan dos modelos de implementación. Un certificado multidominio (SAN/UCC) incluye varios dominios no relacionados entre sí en un único certificado, lo cual resulta útil cuando una organización ofrece numerosos servicios pero desea gestionarlos con un solo certificado. Un certificado «comodín más SAN» combina una entrada comodín con entradas explícitas para hosts que no se ajustan a ese patrón.
SAN y Versa
Versa Los certificados del Servicio de Mensajería (VMS) son el lugar más evidente en el que aparecen las entradas SAN en una implementación de Versa . Al instalar y configurar el VMS, todos los certificados —tanto los certificados de servidor que utilizan los agentes y los dispositivos VOS, como el certificado de la base de datos interna— deben incluir una entrada SAN para cada FQDN o dirección IP en la que responde el clúster: la interfaz de gestión, la interfaz elástica para el tráfico de los agentes y la interfaz de enlace hacia el sur. Tanto el script autofirmado como el flujo de trabajo de la CSR, que solicita entre cinco y siete entradas SAN, garantizan el cumplimiento de este requisito.
Los clústeres de alta disponibilidad elevan aún más los requisitos: una implementación de VMS basada en alta disponibilidad necesita entradas SAN para el FQDN de cada nodo, además del FQDN elástico compartido, de modo que el certificado siga siendo válido independientemente del nodo que responda. La falta de una entrada SAN —a menudo el FQDN elástico, añadido a posteriori— suele provocar fallos de conectividad, ya que el protocolo de enlace falla aunque la ruta de red esté en buen estado.
Preguntas frecuentes
¿Cuál es la diferencia entre un SAN y un nombre común?
El «nombre común» (CN) es un único campo de identidad heredado que figura en el «sujeto» de un certificado; el SAN es una lista que contiene múltiples identidades: nombres DNS, direcciones IP y otros. Los clientes TLS modernos solo realizan la validación con respecto al SAN; el CN se ignora a la hora de comparar identidades, incluso cuando está rellenado.
¿Puede un certificado tener un SAN y carecer de nombre común?
Sí. Los «Requisitos Básicos» del CA/Browser Forum permiten certificados con un «Nombre común» (CN) vacío o ausente, siempre y cuando se incluya el «Nombre alternativo» (SAN), y algunas autoridades de certificación omiten ahora el CN por defecto. El SAN por sí solo es suficiente para la validación de la identidad; ya no depende de nada el CN.
¿Por qué los navegadores dejaron de confiar en el «Common Name»?
El uso del «nombre común» (Common Name) daba lugar a ambigüedades y a un análisis sintáctico inconsistente entre las distintas bibliotecas TLS, lo que los atacantes aprovechaban para obtener certificados engañosos. Chrome dejó de recomendar la coincidencia del CN en 2017, y posteriormente el CA/Browser Forum estableció como obligatorio el uso del SAN para todos los certificados de confianza pública en todo el sector.
¿Qué ocurre si a un certificado le falta una entrada SAN para el servidor al que se está accediendo?
El protocolo de enlace TLS no supera la validación: los clientes y los navegadores rechazan la conexión con un error de discrepancia de nombre, incluso si el nombre común coincide o el certificado es válido por otros motivos. La solución consiste en volver a emitir el certificado añadiendo el host que falta a su lista SAN.
¿Puede la lista SAN de un certificado incluir tanto nombres DNS como direcciones IP?
Sí. Una misma lista SAN puede incluir distintos tipos de entradas —nombres DNS, direcciones IP, direcciones de correo electrónico y URI— siempre y cuando cada entrada haya sido validada por la autoridad de certificación emisora. Es habitual mezclar entradas DNS y de IP en el caso de infraestructuras a las que se puede acceder en ambos sentidos.
Más información sobre SAN
Si quieres saber más, estas son algunas fuentes en las que confiamos.
| RFC 5280: Perfil de certificados PKI X.509 para Internet | NIST SP 800-52, rev. 2: Directrices sobre TLS |
|---|---|
| El estándar de la IETF que define la extensión SAN y cómo los certificados X.509v3 codifican múltiples identidades. | Directrices del NIST sobre la implementación de TLS para validar la identidad del servidor mediante SAN en lugar del nombre común. |
Términos relacionados
Si estás leyendo sobre SAN, te conviene echar un vistazo a lo siguiente.
| Nombre común | Solicitud de firma de certificado | Correo con privacidad mejorada |
|---|---|---|
| El único campo de identidad heredado en el «Subject» de un certificado que SAN sustituye ahora para la validación TLS. | La solicitud enviada a una autoridad de certificación (CA) en la que se especifican la clave pública, el nombre común y las entradas SAN de un certificado antes de la firma. | El formato de texto Base64, delimitado por BEGIN/END, en el que se codifican e intercambian la mayoría de los certificados que contienen un SAN. |