Tengo una aplicación web que utiliza SSL. El sitio web no es público y es para acceso interno privado únicamente en nuestra empresa.
Por razones de seguridad, ejecutamos dos dominios y redes de Active Directory separados, pero los usuarios de ambos dominios pueden acceder a esta aplicación web en particular. Mantenemos CA privadas en cada dominio para generar certificados para servidores web.
La aplicación web en cuestión tiene un certificado válido emitido por una de las CA y todos los usuarios de ese dominio "confían" en el sitio web. Los usuarios del otro dominio pueden acceder al sitio web, pero se les muestra una advertencia de certificado.
Como no quiero entrenar a mis usuarios para que ignoren las advertencias, me gustaría crear algún tipo de relación de confianza entre las CA, pero no sé cómo hacerlo.
Así que para reiterar...
DOMINIO1 y DOMINIO2 tienen cada uno sus propias autoridades de certificación. WEBAPP es miembro de DOMAIN1 y tiene un certificado SSL firmado por la autoridad de certificación de DOMAIN1, por lo que todos los usuarios de DOMAIN1 confían en el certificado. Todos los usuarios de DOMAIN2 reciben errores de certificado.
Respuesta1
No hay forma de que un certificado parezca emitido por más de una autoridad certificadora: es una relación directa entre padre e hijo.
Dos opciones que se me ocurren:
- Confíe en la CA del dominio1 para los clientes del dominio2. Puede importarse a los almacenes de certificados de AD o aplicarse directamente a través de una política de grupo.
- Configure un oyente independiente en el servidor web en un puerto o IP diferente al que accederán los clientes del dominio2, con un certificado emitido por la CA del dominio2.
Respuesta2
Supongo que sus razones de seguridad impiden la creación de un dominio de confianza entre los dos.
Dicho esto: exporte el certificado de CA raíz desde DOMINIO1. Publíquelo como una CA raíz confiablea través de un GPOen DOMINIO2. Sus usuarios deberían dejar de ver advertencias de CA que no son de confianza.
Alternativamente, si los sitios internos en cuestión tienen FQDN enrutables públicamente (es decir, site.com en lugar de site.local), puede ahorrarse mucho tiempo y molestias si obtiene un certificado SSL de 10 dólares de eNom o un proveedor similar. Si le llevará mucho tiempo configurarlo, existe un buen argumento comercial para gastar 10 dólares en lugar de su tiempo más valioso.