Estoy implementando una aplicación multiinquilino donde mi aplicación aloja y sirve documentación técnica para el producto de un inquilino.

Ahora, el enfoque que yo consideraba era - alojo en la documentación docs.<tenant>.mycompany.comy pido a mi inquilino para configurar un registro CNAME DNS a punto docs.tenantcompany.coma docs.<tenant>.mycompany.com.

Quiero que el sitio esté habilitado para SSL con el certificado de mi inquilino. Quería saber si mi empresa inquilina tiene un certificado SSL comodín, ¿funcionará con esta configuración o tendrá que comprar un nuevo certificado SSL docs.tenantcompany.com?

El nombre del certificado debe coincidir con lo que el usuario ingresó en el navegador, no con el registro DNS 'final'. Si el usuario ingresa docs.tenantcompany.com, su certificado SSL debe cubrirlo.

Si docs.tenantcompany.comes un CNAME para foo.example.com, el certificado no necesita cubrir foo.example.com, solo docs.tenantcompany.com.

La respuesta de Jason es correcta. Pero solo para aclarar un poco los términos aquí, "redirección de DNS" es un nombre poco apropiado. DNS tiene registros CNAME (alias) que es un nombre que apunta a otro nombre. Pero no es una redirección. La traducción de nombre a nombre a IP ocurre en segundo plano y su navegador solo se preocupa por el nombre inicial.

Lo único que redirige son los servidores web donde el servidor le dice explícitamente a su navegador que vaya a otro lugar. Si su servidor web fue realmente haciendo una redirección a otro nombre, que sería realmente necesario CERT para ambos nombres porque su navegador en última instancia se conecta a dos de ellos por separado.

Quería saber si mi empresa inquilina tiene un certificado SSL comodín, ¿funcionará con esta configuración o si se debe comprar un nuevo certificado SSL docs.tenantcompany.com?

Respuesta corta: No. Si su empresa inquilina tiene un comodín en el nombre *.tenantcompany.com, eso es suficiente para instalar en su servidor para cubrir los accesos a través de ese nombre. Si quieres hacer esto o no es otra historia.

Un certificado en el nombre docs.<tenant>.mycompany.com(por ejemplo, un certificado directo o un comodín *.<tenant>.mycompany.com) es inútil si el acceso siempre se realiza a través del docs.tenantcompany.comnombre.

Respuesta más larga

Suponga que navega https://docs.tenantcompany.comen un navegador razonable. El navegador ejecuta TLS sobre el protocolo HTTP. Se preocupa específicamente por dos cosas; ese:

• El subsistema DNS del navegador y el sistema operativo devuelve la dirección IP de un host adecuado, que ejecuta un servidor web en un puerto adecuado en otro lugar de la red local o de Internet. Para el tráfico HTTPS (seguro), el puerto predeterminado es a 443menos que se anule en la URL.

• Cuando el protocolo de enlace TLS se lleva a cabo entre el navegador y el servidor remoto, el servidor presenta un certificado de confianza que le permite proporcionar un servicio TLS en la dirección solicitada ( docs.tenantcompany.com).

DNS

El navegador ve DNS como un cuadro negro. Hace una llamada a una biblioteca DNS adecuada para solicitar una asignación de un nombre de dominio completo y amigable (FQDN) a una dirección IP adecuada (v4 o v6). No le importa cómo obtiene esa dirección IP. Si hay 20 CNAMEalias en el DNS entre el registro original y un registro Ao AAAA, el solucionador DNS los seguirá hasta que se obtenga una dirección IP.

TLS

Cuando el navegador realiza la TLS apretón de manos , es necesario verificar que el servidor se está comunicando con está autorizado para proporcionar un servicio web seguro en el FQDN solicitada: docs.tenantcompany.com.

Recuerde: al navegador no le importa docs.<tenant>.mycompany.com: el solucionador de DNS ha abstraído todo conocimiento de la indirección a través de un CNAMEregistro.

Nuestro método para autorizar al servidor a servir sesiones seguras docs.tenantcompany.comes mediante un certificado SSL firmado por una autoridad para la cual se ha establecido una confianza previa en el almacén de certificados raíz del navegador. Esta no es siempre la forma más fuerte de autenticación del servidor al cliente (muchos pueden salir mal en el modelo de CA centralizado), pero es lo mejor que tenemos en este momento.

Hay dos advertencias más aquí:

Intercambio de claves

Muchos proveedores de certificados SSL comerciales solo firmarán una única solicitud de firma, que efectivamente vincula el certificado comodín a una sola clave privada. La empresa inquilina puede sentirse incómoda al compartir esto fuera de su organización, ya que cualquier persona que posea la clave privada obviamente puede comprometer la comunicación con los otros sistemas seguros de la empresa inquilina.

Algunos proveedores firmarán múltiples solicitudes de firma de certificados bajo el mismo certificado, lo que permite instalar un solo certificado comodín en varios servidores y sistemas sin compartir la clave privada entre ellos.

Disfraces

Si la empresa inquilina le proporciona una copia de su certificado comodín (ya sea compartiendo la clave privada o firmando su propia CSR), puede hacerse <anydomain>.tenantcompany.compasar por una protección importante que garantiza la integridad de los servidores identificados en el tenantcompany.comespacio de nombres DNS. Esta podría ser una mala posición tanto para usted como para la empresa inquilina, desde una perspectiva legal / de responsabilidad.