Comprensión de SAN en certificados SSL X.509

¿Qué es el Nombre Alternativo del Sujeto (SAN) en los certificados SSL/TLS? 

El nombre alternativo del sujeto (SAN) es una extensión importante del Certificado X.509 estándar, definido en RFC 5280Permite que los certificados SSL/TLS incluyan múltiples identidades más allá del campo de Nombre Común (CN). Estas identidades pueden incluir nombres de dominio, subdominios, direcciones IP, direcciones de correo electrónico y más, lo que facilita la comunicación segura entre una amplia variedad de puntos finales. 

Al utilizar la extensión SAN, las organizaciones pueden mejorar significativamente la flexibilidad, escalabilidad, y seguridad de sus certificados SSL. En lugar de administrar certificados separados para cada dominio o servicio, un certificado habilitado para SAN puede proteger todas las identidades requeridas bajo un único certificado, lo que simplifica la gestión de certificados y reduce la sobrecarga operativa. 

Antes de SAN: La limitación del nombre común (CN) 

En los certificados SSL anteriores, el nombre de dominio protegido por el certificado se identificaba principalmente a través del campo CN. 

 Ejemplo: 

 Si el CN ​​fue: 

CN = www.ejemplo.com 

El certificado sólo será válido para: 

• www.example.com 

Si un usuario visitó: 

• example.com 
• blog.ejemplo.com 
• www.ejemplo.net 

Recibirían una advertencia de seguridad porque el certificado no coincide con el dominio solicitado. Los navegadores modernos ya no utilizan el campo CN para la validación del dominio; ahora solo validan las entradas del campo SAN para mayor seguridad y coherencia, según los estándares actuales del sector. 

Desventajas de depender únicamente de CN

• Sólo se podrá proteger un único nombre de dominio completamente calificado (FQDN). 

• No hay flexibilidad para incluir subdominios o dominios alternativos. 

• Varios servicios/dominios requieren certificados separados. 

• Práctica obsoletaNo se recomienda confiar únicamente en CN debido a riesgos de seguridad y problemas de compatibilidad, ya que muchos navegadores modernos ignoran el CN ​​y confían únicamente en la lista SAN para la validación del dominio. 

Después de SAN: Múltiples dominios, un certificado 

Mediante el uso de la SAN extensión, una sola Certificado SSL / TLS puede asegurar identidades múltiples en diferentes servicios. Estas identidades pueden incluir: 

• Subdominios (por ejemplo, blog.ejemplo.com) 
• Dominios completamente diferentes (por ejemplo, ejemplo.net) 

• Direcciones IP (por ejemplo, 203.0.113.5) – Nota: Las direcciones IP en SAN deben coincidir exactamente; no hay soporte para subredes o coincidencias parciales. 
• Nombres de host internos (por ejemplo, intranet.local) 
• Dominios comodín (p. ej., *.example.com) – Las entradas con comodines en los campos SAN tienen limitaciones: solo coinciden con un nivel de subdominio (p. ej., *.example.com coincide con blog.example.com, pero no con dev.blog.example.com), y no todas las autoridades de certificación (CA) admiten entradas con comodines en los SAN. Verifique siempre la compatibilidad y las políticas de la CA antes de usarlas. 

Ejemplo: 

Un certificado habilitado para SAN podría tener: 

CN = www.ejemplo.com 

SAN: 

  DNS.1 = www.ejemplo.com 

  DNS.2 = ejemplo.com 

  DNS.3 = blog.ejemplo.com 

  DNS.4 = www.ejemplo.net 

  IP.1 = 203.0.113.5 

Este certificado es válido para todas las entradas DNS e IP enumeradas. 

Beneficios: 

• Un único certificado puede proteger múltiples servicios. 
• Simplifica la gestión: una renovación, una instalación. 
• Es rentable ya que elimina la necesidad de comprar certificados individuales. 
• Admite infraestructura web moderna como microservicios, API y plataformas multidominio. 
• SAN es ahora un componente obligatorio en todos los sistemas de confianza pública.
• Certificados SSL, según la CA / Foro del navegador Requisitos básicos: los navegadores modernos se basan exclusivamente en el campo SAN para la validación del dominio. 

¿Por qué utilizar un certificado SSL SAN?  

• Proteja varios dominios con un solo certificado
  Proteja todos los dominios bajo un único certificado SSL, lo que facilita a las organizaciones la gestión de múltiples sitios web.
  Sin embargo, es importante tener en cuenta que cada entrada SAN debe validarse individualmente durante la emisión del certificado. La mayoría de las CA requieren la validación de dominio basada en DNS o HTTP para cada dominio incluido en la lista SAN, a fin de garantizar la propiedad y el cumplimiento de las normas de seguridad.
• Gestión de certificados simplificada
  Reduce la complejidad y los errores humanos al administrar, renovar e implementar un solo certificado en lugar de varios.
• Reducción de costes
  Reduce gastos al no tener que comprar varios certificados: muchos certificados SAN admiten hasta 100 dominios.
• Admite infraestructuras complejas
  Perfecto para configuraciones modernas como microservicios, API y plataformas en la nube que utilizan diferentes subdominios o dominios.
• Necesario para la compatibilidad del navegador
  Los navegadores modernos utilizan el campo SAN, lo que hace que SAN sea una parte obligatoria de los certificados SSL públicos.
• Escalable para expansión futura
  Agregar dominios al certificado durante la renovación o reemisión es fácil, lo cual es excelente para las empresas en crecimiento.
• Aumenta la confianza y el SEO
  HTTPS en todos los dominios genera confianza en el usuario, protege los datos y mejora la clasificación de búsqueda de Google.

¿Cómo funciona un certificado SAN? 

Creación de certificados con SAN 

Durante la generación de una solicitud de firma de certificado (CSR), el administrador especifica una lista de entradas SAN. Estas pueden ser: 

• Nombres de dominio completos (FQDN) 
• Subdominios 
• Direcciones IP 
• Las direcciones de correo 
• URIs (para aplicaciones especializadas) 

Para incluir estos valores SAN, el administrador debe definirlos en el campo subjectAltName dentro del archivo de configuración CSR (normalmente openssl.cnf o equivalente). 
Una vez creado el CSR y enviado a una CALa CA verifica la propiedad o el control de cada entrada SAN. Tras una validación exitosa, la CA emite un certificado con las entradas SAN codificadas en la extensión SAN. 

El navegador/cliente realiza una solicitud segura 

Cuando un cliente (como un navegador o una aplicación) se conecta a un sitio web seguro a través de HTTPS: 

• Durante los Apretón de manos TLS, el servidor presenta su certificado SSL al cliente. 
• El certificado incluye: 
  1. la clave publica 
  2. El CN (campo heredado) 
  3. La extensión SAN con todas las identidades válidas

Como parte del protocolo de enlace, el cliente realiza una verificación del nombre de host, comprobando si el dominio solicitado coincide con alguna de las entradas del campo SAN. Este paso de verificación es fundamental para establecer la confianza; los clientes modernos se basan exclusivamente en la extensión SAN para esta comprobación, ignorando el campo CN. 

El cliente valida la lista SAN 

Los navegadores modernos se basan en la lista SAN e ignoran el CN. El cliente busca una coincidencia entre: 

• El nombre de dominio al que intenta conectarse. 
• Cualquiera de los nombres enumerados en el campo SAN. 

La conexión se realiza de forma segura sólo si se encuentra una coincidencia comodín exacta o válida. 

• Comportamiento del comodín: Los navegadores admiten entradas SAN con dominios comodín (p. ej., *.example.com), pero el comodín solo puede coincidir con un nivel de subdominio. Por ejemplo, *.example.com coincide con blog.example.com, pero no con shop.dev.example.com. 
• Nombres internosLos navegadores y las CA modernas ya no aceptan nombres internos (como localhost o server.local) en los certificados públicos. Incluir dichos nombres hará que el certificado se considere inválido o no confiable. 

Si no se encuentra ninguna coincidencia, el navegador muestra una advertencia de seguridad, como “Su conexión no es privada” o “Certificado no válido”. 

Un certificado, muchos dominios 

Dado que la lista SAN incluye varias identidades, se puede utilizar un certificado en: 

• Varios sitios web (por ejemplo, ejemplo.com, ejemplo.net) 
• Múltiples subdominios (por ejemplo, tienda.ejemplo.com, blog.ejemplo.com) 
• Diferentes servicios (por ejemplo, Exchange Server, servidor de correo, puerta de enlace API) 

Esto hace que la gestión sea fácil y sencilla, ya que ahora no es necesario instalar y gestionar certificados separados para cada dominio. 

Casos de uso comunes para certificados SAN (nombre alternativo del sujeto) 

Los certificados SAN se utilizan en numerosos sectores e infraestructuras gracias a su compatibilidad con múltiples dominios. Permiten proteger varios dominios, subdominios y direcciones IP con un único certificado, lo que los convierte en la solución ideal para organizaciones que buscan escalabilidad y simplicidad. 

 Cómo proteger varios sitios web bajo una sola organización 

Caso de uso

Una empresa posee múltiples sitios web o dominios de marca: 

• example.com 
• example.net 
• example.org 
• producto.ejemplo.com 
• soporte.ejemplo.net 

No es necesario comprar ni administrar certificados SSL separados para cada uno, ya que ahora una empresa puede usar un único certificado SAN para proteger todos los dominios y subdominios. 

Nota: Cada subdominio debe estar explícitamente listado en el campo SAN, a menos que se incluya una entrada comodín (p. ej., *.ejemplo.com). Sin comodín, la coincidencia con el subdominio es exacta y el certificado no cubrirá los subdominios no listados. 

Beneficios

• Gestión centralizada 
• En ahorro de costes 
• Renovaciones e instalaciones más fáciles 

Protección de aplicaciones con múltiples subdominios 

Caso de uso 

Una aplicación web opera en varios subdominios: 

• login.example.com (autenticación) 
• api.example.com (API de back-end) 
• dashboard.example.com (portal de usuario) 
• cdn.example.com (entrega de contenido estático) 

Todos los subdominios se agregan como entradas SAN en un certificado. 

Beneficios

• Simplifica la implementación 
• Reduce la proliferación de certificados 
• Ciclo unificado de vencimiento y renovación 

Arquitecturas basadas en la nube y microservicios 

Caso de uso

Las aplicaciones modernas, aquellas que utilizan microservicios o plataformas en la nube, operan en: 

• Diferentes subdominios 
• Regiones o instancias separadas 
• Diferentes dominios de nivel superior (TLD) 

Ejemplo: 

• us.api.example.com 
• eu.api.example.net 
• static.cdnexample.org 

Se puede utilizar un certificado SAN para proteger todos estos servicios, incluso si están distribuidos geográficamente o abarcan múltiples dominios. 

Consideración: Si bien los certificados SAN simplifican la administración, vincular demasiados servicios a un solo certificado puede crear un punto único de fallo. Si el certificado caduca, se ve comprometido o necesita ser reemitido, todos los servicios que dependen de él se ven afectados simultáneamente. Para mitigar esto, las organizaciones deben agrupar cuidadosamente los servicios por riesgo y entorno, y utilizar certificados SAN separados cuando corresponda. 

Beneficios

• Automatización de certificados más sencilla (por ejemplo, mediante CI/CD) 
• Menos certificados para renovar, menos configuraciones erróneas 
• Comunicación de servicios segura en configuraciones de nube híbrida 

Entornos de desarrollo, preparación y prueba 

Caso de uso

Los desarrolladores quieren usar HTTPS en dominios locales o de prueba: 

• dev.ejemplo.local 
• puesta en escena.ejemplo.com 
• prueba-api.ejemplo.org 

Todos los entornos están protegidos mediante certificados SAN, por lo que no es necesario utilizar múltiples certificados. 

Para entornos internos como los dominios .local (p. ej., dev.example.local), se recomienda usar una CA interna o un certificado SAN autofirmado. Las CA públicas ya no emiten certificados para nombres internos debido a las restricciones de seguridad impuestas por el Foro CA/Browser. 

Beneficios

• Permitir pruebas precisas y más seguras en condiciones reales HTTPS . 
• Canales de pruebas CI/CD más rápidos. 
• Se reduce la carga de la gestión manual de certificados. 

Microsoft Exchange Server y Office 365 

Caso de uso 

Microsoft Exchange y Skype for Business requieren certificados SAN para que funcionen correctamente con múltiples servicios internos y externos, como: 

• correo.ejemplo.com 
• autodiscover.example.com 
• smtp.ejemplo.net 
• Interno.intercambio.local 

Para simplificar la implementación, Microsoft recomienda certificados que admitan múltiples entradas SAN. 

A Certificado de Comunicaciones Unificadas (UCC) Se utiliza a menudo en estos casos. Si bien UCC se conoce comúnmente como un certificado especial, es esencialmente un término de marketing para un certificado multi-SAN optimizado para aplicaciones de Microsoft como Exchange, Skype Empresarial y Office 365. 

Beneficios

• Es totalmente compatible con el marco de confianza de Microsoft para la gestión de certificados. 
• No es necesario contar con múltiples certificados, un solo certificado puede proteger todos los servicios (correo electrónico, calendario, descubrimiento automático, etc.) 
• Fácil configuración para implementaciones híbridas de Office 365 

Qué tener en cuenta al elegir una CA para certificados SAN

Reputación y nivel de confianza

Elija una CA de confianza global que sea: 

• Reconocido por todos los navegadores y sistemas operativos líderes. 
• Cumpliendo con todas las directrices establecidas por los estándares del Foro CA/Browser. 
• Conocida por implementar altos estándares de seguridad. 

CA de confianza populares: 

• DigiCert 
• Sectigo (anteriormente Comodo) 
• confiar 
• GlobalSign 
• Ve papi 
• Let's Encrypt (para casos de uso limitados, compatible con SAN) 

Nota: Aunque Vamos a cifrar Es ampliamente confiable e ideal para implementaciones automatizadas a corto plazo, puede No es adecuado para vidas útiles de certificados más largas or necesidades empresariales complejas que requieren validación extendida (EV), validación de la organización (OV) o funciones avanzadas de soporte y generación de informes. 

Por qué es importante: Con la confianza pública, los usuarios no ven las advertencias sobre “Certificado no confiable”. 

Precios y licencias 

Los precios de los certificados SAN pueden fluctuar según: 

• Número de SAN incluidas (algunas incluyen entre 2 y 5 SAN de forma predeterminada) 
• Costo por entrada SAN adicional 
• Nivel de validación (DV, OV, EV) 

Precaución: Sea consciente del potencial vendedor encerrado y costos de renovación inesperadosAlgunas CA ofrecen precios iniciales bajos, pero cobran tarifas significativamente más altas durante la renovación o al añadir nuevas entradas SAN. Revise siempre el modelo de precios completo y las condiciones de renovación antes de comprometerse. 

Por qué es importante: La escalabilidad puede verse afectada por el precio, especialmente si se administran muchos dominios simultáneamente. 

Tipo de validación del certificado 

Las CA ofrecen tres tipos de validación: 

Tipo de validación	Nivel de verificación	Indicadores de confianza	Uso recomendado
DV (Validación de Dominio)	Verifica únicamente la propiedad del dominio	Candado en el navegador	Sitios internos, blogs personales, aplicaciones de bajo riesgo
OV (Validación de la Organización)	Verifica la identidad del dominio y la organización	Candado + detalles de la organización en la información del certificado	Sitios web comerciales, API, aplicaciones públicas
EV (Validación extendida)	Investigación exhaustiva de la existencia legal y empresarial	Candado + nombre de la organización en la barra de direcciones del navegador (en algunos navegadores)	Servicios financieros, comercio electrónico, industrias reguladas

Para manejar datos confidenciales, ejecutar servicios públicos o aspirar a un alto nivel de confianza, debe elegir OV o EV. 

Facilidad de gestión de certificados 

Busque CA que ofrezcan: 

• Paneles de gestión o API 
• Automatización de certificados (por ejemplo, a través de CUMBRE protocolo) 
• Recordatorios de renovación 
• SAN admite la reemisión flexible (añadir/eliminar dominios fácilmente). 

Por qué es importante: Una gestión eficiente y simplificada reduce los gastos generales y ayuda con los problemas de caducidad de los certificados. 

Soporte para requisitos personalizados

Considerar: 

• Compatibilidad con SAN comodín (por ejemplo, *.example.com) 
• Inclusión de direcciones IP 
• Compatibilidad con dominios internos (por ejemplo, dev.local) 
• Integración con su infraestructura (por ejemplo, Microsoft Exchange, AWS, Kubernetes) 

Nota: No todas las autoridades de certificación admiten la combinación de dominios comodín y entradas SAN en un mismo certificado. Algunas imponen restricciones o pueden requerir un nivel de producto diferente. Asegúrese de verificar esta funcionalidad si su caso de uso incluye ambos. 

Por qué es importante: Algunas CA pueden necesitar configuraciones especiales u ofrecer soporte limitado para nombres internos, direcciones IP o configuraciones complejas de comodín/SAN; comprender estos límites ayuda a evitar problemas de implementación. 

Atención al cliente y SLA 

Al evaluar un CA, priorizar aquellos que ofrecen: 

• soporte 24/7 
• SLA de emisión y reemisión rápidas 
• Soporte empresarial dedicado (para implementaciones grandes) 

El tiempo de emisión es importanteAlgunas CA pueden emitir certificados de Validación de Dominio (DV) en cuestión de minutos, mientras que los certificados OV/EV pueden tardar horas o días, dependiendo de los procesos de verificación. 
Tiempo de inactividad de la reemisión También debe tenerse en cuenta que las demoras en el reemplazo de certificados vencidos o comprometidos pueden provocar interrupciones del servicio o advertencias de seguridad para los usuarios. 

Por qué es importante: El soporte oportuno es esencial ante cortes o renovaciones. 

Cómo puede ayudar la consultoría de cifrado 

Gestionar certificados SAN para múltiples dominios, subdominios e IP puede convertirse rápidamente en un desafío, especialmente a gran escala. Aquí es donde entra en juego CertSecure Manager de Encryption Consulting. 

Nuestros Gestión del ciclo de vida de los certificados (CLM) La solución automatiza y optimiza todo el proceso, desde el descubrimiento y la emisión hasta la renovación y la revocación. Ya sea que esté protegiendo servicios internos, cargas de trabajo en la nube o entornos multidominio complejos, Administrador de CertSecure ofrece: 

• Inventario de certificados centralizado, incluidas las entradas SAN 
• Emisión y renovación automatizadas mediante las principales CA 
• Controles basados ​​en políticas y flujos de trabajo de aprobación 
• Alertas en tiempo real para evitar vencimientos o configuraciones incorrectas 
• Registros de auditoría detallados e informes de cumplimiento 

Integraciones compatibles: CertSecure Manager se integra perfectamente con las principales plataformas de CA como DigiCert, Sectigo y otras a través de su APITambién admite clientes basados ​​en el protocolo ACME (por ejemplo, Let's Encrypt) y puede conectarse con herramientas de infraestructura como Microsoft CA, AWS y Azure Key Vault. 

Con CertSecure Manager, las organizaciones pueden administrar con confianza los certificados SSL SAN con eficiencia, visibilidad y control, todo desde una única plataforma. 

Conclusión 

Los certificados SAN ofrecen una solución inteligente y escalable para proteger múltiples dominios, subdominios y servicios con un solo certificado. Tanto si gestiona una infraestructura compleja como si simplemente busca simplificar la gestión de SSL, los certificados SAN proporcionan flexibilidad, rentabilidad y una seguridad robusta, lo que los convierte en elementos esenciales para los entornos digitales modernos.