¿Es técnicamente posible configurar dos certificados SSL diferentes para el mismo dominio?

Sí y No.

Es posible tener varios certificados que tengan el mismo nombre de dominio. Podría tener un certificado Comodo example.org y un certificado Entrust example.org, ambos válidos y oficiales, no hay problema. Creo que algunos balanceadores de carga rotarán cuál se usa por conexión, pero solo de forma rotatoria.

El No indica que puede seleccionar qué certificado utilizar según el URI (/ vs. / criticalpath). El problema es que el URI solo está disponible después de que la conexión SSL se haya establecido mediante uno de los dos certificados. Por lo tanto, realmente no puede elegir qué certificado utilizar basándose en la información que solo puede tener después de haber elegido el certificado.

Ahora, no voy a decir que 100% es imposible. Con Apache, por ejemplo, puede configurar la configuración de SSLCipherSuite por directorio , por lo que no me sorprendería si hubiera alguna manera de forzar una renegociación que involucrara un nuevo certificado. Pero más bien sospecho que prácticamente no está implementado, incluso si es teóricamente posible. (Apache SSLCertificate * es por servidor o por host, no por directorio).

Apéndice : Reflexiones sobre la renegociación

Descargo de responsabilidad: no he hecho nada de esto, es una interpretación sencilla de los RFC y otros documentos. Decenas de personas aquí están mucho más calificadas para comentar que yo.

Voy a ver TLS 1.2, ya que está bien descrito en RFC 5246 .

Sección 7.4.1.1, "El servidor puede enviar el mensaje HelloRequest en cualquier momento". Eso debería hacer que el Cliente renegocie la conexión. (El cliente PUEDE ignorar esa solicitud y el servidor PUEDE interrumpir la conexión si el cliente ignora la solicitud por demasiado tiempo).

Una renegociación se parece mucho a una negociación inicial, aunque puede pasar algo de información de la negociación anterior hacia adelante para intentar suavizar el camino (por ejemplo, este es el código que acordamos la última vez ). Entonces, el Cliente envía un ClientHello , luego el servidor envía un ServerHello , luego el servidor envía un Server Certificate ( 7.4.2).

Mi lectura del RFC es que, sí, un servidor puede forzar la renegociación de una conexión, incluida la selección de un certificado de servidor diferente.

Seré honesto contigo, no sé que encontrarás el software existente que hará lo que quieras hacer. Le sugiero que comience a jugar con Perl Crypto :: OpenSSL o con Python's ssl lib para ver si puede probarlo.

No. Ningún servidor web puede soportar esta característica; No ahora, ni nunca. He aquí por qué:

HTTPS sigue estos pasos en este orden:

1. El cliente se conecta al servidor
2. Negociación SSL / TLS (incluye intercambio de certificados, verificación de certificados y configuración de cifrado)
3. El cliente envía la solicitud (incluye el nombre de host del servidor, la ruta, las cookies, etc.)
4. El servidor envía una respuesta (incluye encabezados de respuesta, contenido, etc.)

Tenga en cuenta que el paso 2 anterior ocurre antes que el paso 3. Es decir, todo el proceso de cifrado está totalmente terminado antes de que el navegador le diga al servidor qué URL está buscando. Esto significa que cuando el servidor selecciona un certificado SSL para usar, aún no sabe cuál será la ruta de la URL. Dado que esta información no está disponible en esa etapa, no puede tener en cuenta la decisión de qué certificado usar.

También tenga en cuenta que el nombre de host se envía al servidor en el paso 3, razón por la cual cada certificado generalmente se instala en direcciones IP únicas; el servidor utiliza la dirección IP para determinar qué certificado presentar. Las versiones más nuevas de SSL / TLS agregaron una extensión llamada Identificación del nombre del servidor para permitir que el cliente especifique el nombre de host durante la negociación de TLS, pero esto solo funciona para nombres de host.

No hay ninguna disposición para permitir la selección de certificados basada en la ruta de la URL, ni la habrá, porque eso implicaría que la ruta de la URL debe enviarse al servidor sin cifrar como parte de la selección del certificado. Y enviar la URL sin cifrar sería inaceptable para una página segura.

Estoy pensando que puede ser posible utilizando la descarga de SSL, la inspección profunda de paquetes y la renegociación de TLS. Sin embargo, si realiza una renegociación de TLS en Google, los 20 primeros éxitos serán sobre vulnerabilidades de renegociación. Por lo tanto, si lo hace, puede terminar haciendo que su sitio sea menos seguro, no más.

Por otro lado, si tu esquema fuera así:

enlace

enlace

sería bastante trivial. Simplemente direccionaría esos dos dominios a diferentes direcciones IP internas y vincularía las direcciones IP a certificados diferentes.