Pedir un certificado SSL del cliente

El problema es que con HTTPS, SSL ocurre primero y luego HTTP dentro de el túnel SSL. Cuando se contacta con el servidor y debe enviar su certificado, aún no conoce el nombre del servidor con el que el cliente desea hablar (el nombre de la URL que ve el cliente).

Hay principalmente tres métodos fuera de esto:

1. Usa una IP diferente para cada nombre. Cuando se produce la conexión, el servidor conoce la dirección IP utilizada por el cliente, por lo que el servidor podría proporcionar un certificado diferente según esa dirección.

2. Use un certificado con varios nombres. El cliente desea ver el nombre del servidor deseado en el certificado, pero puede haber más de un nombre en un certificado. La extensión de certificado Subject Alt Name puede contener muchos nombres (¡los certificados de Google contienen más de 70 nombres!).

3. Haga que el cliente anuncie el nombre del servidor deseado con suficiente antelación en el protocolo SSL. Hay una extensión SSL para eso: Indicación del nombre del servidor . La buena noticia es que la mayoría de los navegadores web lo implementan. La mala noticia es que solo los navegadores web de la mayoría lo implementan; en particular, Internet Explorer en Windows XP no lo hace (IE 8 en Vista y versiones posteriores lo admite, pero no en XP).

Consulte este sitio para obtener estadísticas sobre el uso del navegador web en Internet (utilícelos como estimaciones, no como evangelio; cualquier comunidad de usuarios determinada) pueden exhibir diferentes patrones de uso). A partir de hoy (octubre de 2013), IE 8 se anuncia con un poco menos del 10% de participación de mercado (el sitio no dice cuántos de estos funcionan en WinXP, pero apuesto a que la mayoría sí lo hacen).

El método 3 es la "mejor práctica", o al menos será la mejor práctica en el futuro cercano. También es el único método que puede implementar de inmediato sin pedirle a su gran cliente que cambie su DNS o que solicite un certificado con el nombre adicional.

Solución 1

Hay una forma de hacerlo, pero es tan esotérico que sería mejor esperar a que la empresa cliente le otorgue un certificado apropiado (o consulte Solución 2 ). Especialmente ya que Solución 1 * podría generar ciertos riesgos de auditoría, ya que los auditores son notoriamente conservadores de las soluciones tecnológicas.

Pero si usted y los técnicos de la empresa cliente prefieren pedir perdón en lugar de permiso, puede hacer lo siguiente:

1. Los técnicos del cliente configuran un servicio web seguro que tiene acceso a uno de sus certificados SSL que coincide con el dominio del cliente en cuestión. Este servicio web se bloqueará en un grado insano específico para su servidor.
2. Su servidor admite la extensión Indicación del nombre del servidor para TLS.
3. Si el navegador llega con un RFC-6066 server_name que coincide con su dominio, proceda como de costumbre. El navegador obtiene felizmente el certificado para el dominio que esperaba, todo está feliz en el mundo.
4. Si el navegador llega con un RFC-6066 server_name que coincide con el dominio cliente , cambie su protocolo de enlace TLS al modo proxy transparente y reenvíe todo el tráfico al servicio web especial del cliente **. Ahora estás actuando como proxy / enrutador de paquetes, no hay nada divertido en el medio.
5. El servicio web del cliente hace su trabajo con el certificado que espera el navegador y devuelve una redirección temporal 302 cifrada a su dominio. p.ej. %código%. Es todo lo que este servicio web de cliente debe hacer.
6. La conexión TLS está cortada. Y más adelante, obtendrás una solicitud de conexión diferente para HTTPS a tu dominio desde ese navegador. No es que hayas sabido que recibieron una instrucción de redireccionamiento, ya que ese era un tráfico que no podías descifrar, sino simplemente un proxy. ;-)

Entonces:

A. Browser ===[client.com]==> https://vendor.com ==(client W/S)==> https://client.com

B. https://client.com ==[302 redirect]==> http://vendor.com ==[302 redirect]==> Browser

C. Browser ==[vendor.com]==> https://vendor.com

_{* Solution 1 se me ocurrió primero y sí permite que el CNAME (¿mal configurado?) siga apuntando a la IP del proveedor; de lo contrario, convertiría a Solución 2 en la primera solución.
** Nunca he visto esto en la naturaleza, así que no estoy seguro de si hay un proxy transparente La mitad de un protocolo SSL funcionaría en la práctica.}

Solución 2

La solución 1, por supuesto, supone que no ocultan su servicio debajo de su dominio por XSS o por otros motivos de agregación de contenido.

Si lo son, la solución mucho más común es pedirles que no establezcan su CNAME de dominio en su IP * pero que configuren un proxy inverso HTTPS de cliente que se comunique con su sitio bajo el capó.

_{* Cosa estúpida que hacer para HTTPS: debido a la ambigüedad de propiedad y control que causa a los proveedores.}

Sí, puede ejecutar varios certificados SSL a través de varios nombres de host en el mismo servidor.

¿Qué servidor web utilizas? Creo que esto es más bien un tema para serverfault.