tipo - SSL: ¿cómo funcionan conjuntamente los nombres comunes(CN) y los nombres alternativos de sujeto(SAN)?

ssl con nombre (3)

Suponiendo que la propiedad Nombre alternativo del sujeto (SAN) de un certificado SSL contiene dos nombres DNS

domain.tld
host.domain.tld

pero el Nombre común (CN) se establece en solo uno de los dos: CN=domain.tld .

¿Tiene esta configuración un significado especial, o alguna [des] ventajas sobre la configuración de ambos CN?
¿Qué sucede en el lado del servidor si se está solicitando el otro, host.domain.tld ?

EDITAR:

Como aprendí recientemente la respuesta de Eugene, que el comportamiento difiere según la implementación, quiero ser más específico: ¿cómo maneja OpenSSL 0.9.8b + el escenario dado?

Requisitos básicos de CABForum

Veo que nadie ha mencionado la sección en los Requisitos básicos aún. Siento que son importantes.

P: SSL: ¿cómo funcionan conjuntamente los nombres comunes (CN) y los nombres alternativos de sujeto (SAN)?
R: No, en absoluto. Si hay SAN, entonces CN puede ignorarse. - Al menos, si el software que realiza la verificación cumple estrictamente con los requisitos de referencia del CABForum.

(Entonces, esto significa que no puedo responder el "Editar" a su pregunta. Solo la pregunta original).

Requisitos básicos de CABForum, v. 1.2.5 (desde el 2 de abril de 2015), página 9-10 :

9.2.2 Campos de nombres distinguidos del sujeto
a. Campo de nombre común del sujeto
Campo del certificado: subject: commonName (OID 2.5.4.3)
Obligatorio / Opcional: Obsoleto (Desanimado, pero no prohibido)
Contenido: Si está presente, este campo DEBE contener una única dirección IP o un nombre de dominio completo que sea uno de los valores contenidos en la extensión subjectAltName del certificado (consulte la Sección 9.2.1).

EDITAR: Enlaces del comentario de @ Bruno

RFC 2818: HTTP sobre TLS , 2000, Sección 3.1: Identidad del servidor :

Si está presente una extensión subjectAltName de tipo dNSName, DEBE utilizarse como identidad. De lo contrario, DEBE utilizarse el campo de Nombre común (más específico) en el campo Asunto del certificado. Aunque el uso del Nombre común es una práctica existente, está en desuso y se recomienda a las Autoridades de certificación que usen el Nombre DNS en su lugar.

RFC 6125: Representación y verificación de identidad de servicio de aplicación basada en dominio dentro de infraestructura de clave pública de Internet utilizando certificados X.509 (PKIX) en el contexto de Seguridad de la capa de transporte (TLS) , 2011, Sección 6.4.4: Comprobación de nombres comunes :

[...] si y solo si los identificadores presentados no incluyen un DNS-ID, SRV-ID, URI-ID o cualquier tipo de identificador específico de la aplicación compatible con el cliente, entonces el cliente PUEDE como último recurso verificar una cadena cuya forma coincide con la de un nombre de dominio DNS totalmente calificado en un campo de Nombre común del campo de asunto (es decir, un CN-ID).

Esto depende de la implementación, pero la regla general es que el dominio se compara con todas las SAN y el nombre común. Si el dominio se encuentra allí, entonces el certificado está bien para la conexión.

RFC 5280 , sección 4.1.2.6 dice "El nombre del sujeto PUEDE ser llevado en el campo de asunto y / o la extensión subjectAltName". Esto significa que el nombre de dominio se debe comparar con la extensión SubjectAltName y la propiedad Subject (es decir, su parámetro de nombre común) del certificado. Estos dos lugares se complementan entre sí y no se duplican. Y SubjectAltName es un lugar apropiado para poner nombres adicionales, como www .domain.com o www2 .domain.com

Actualización: según RFC 6125 , publicado en ''2011, el validador debe verificar primero SAN y, si existe SAN, entonces no se debe verificar CN. Tenga en cuenta que el RFC 6125 es relativamente reciente y todavía existen certificados y CA que emiten certificados, que incluyen el nombre de dominio "principal" en CN y nombres de dominio alternativos en SAN. Es decir, al excluir CN de la validación si SAN está presente, puede denegar algún certificado válido.

Para ser absolutamente correcto, debe poner todos los nombres en el campo SAN.

El campo CN debe contener un nombre de sujeto, no un nombre de dominio, pero cuando Netscape descubrió este aspecto de SSL, omitió definir su mayor mercado. Simplemente no había un campo de certificado definido para la URL del servidor.

Esto se resolvió para poner el dominio en el campo CN, y hoy en día el uso del campo CN está en desuso, pero aún se usa ampliamente. El CN puede contener solo un nombre de dominio.

Las reglas generales para esto: CN - ponga aquí su URL principal (para compatibilidad) SAN - ponga todo su dominio aquí, repita el CN porque no está en el lugar correcto allí, pero se usa para eso ...

Si encontró una implementación correcta, las respuestas a sus preguntas serán las siguientes:

¿Tiene esta configuración un significado especial, o alguna [des] ventajas sobre la configuración de ambos CN? No puede establecer ambos CN, porque CN puede contener solo un nombre. Puede hacer con 2 certificados CN simples en lugar de un certificado CN + SAN, pero necesita 2 direcciones IP para esto.
¿Qué sucede en el lado del servidor si se está solicitando el otro, host.domain.tld? No importa lo que suceda en el lado del servidor.

En resumen: cuando un cliente de navegador se conecta a este servidor, el navegador envía paquetes cifrados, que se cifran con la clave pública del servidor. El servidor descifra el paquete y, si el servidor puede descifrar, se cifró para el servidor.

El servidor no sabe nada del cliente antes de descifrar, porque solo la dirección IP no está encriptada a través de la conexión. Es por eso que necesita 2 direcciones IP para 2 certificados. (Olvídese de SNI, todavía hay demasiadas XP por ahí).

En el lado del cliente, el navegador obtiene el CN, luego el SAN hasta que todos estén marcados. Si uno de los nombres coincide para el sitio, la verificación de URL fue realizada por el navegador. (No hablo de la verificación del certificado, por supuesto, muchas ocsp, crl, aia request y respuestas viajan en la red cada vez).