Cómo configurar el equilibrador de carga F5 y el servidor backend ambos con certificados SSL

Navega tus respuestas
2

Tengo un F5 equilibrador de carga y un servidor backend . El equilibrador de carga es www.example.com . El servidor backend es server1.example.com . Tengo el equilibrador de carga F5 con SSL Profile (client) y SSL Profile (server) habilitados y certificados SSL en el equilibrador de carga y el servidor backend. Así que se ve así:

  

Cliente (computadora portátil) - > HTTPS / SSL - > F5 Load Balancer (www.example.com) - > HTTPS / SSL   - > Servidor backend (server1.example.com)

El servidor backend está ejecutando Windows 2012 / IIS 8.5 . En los enlaces, el campo Nombre de host está en blanco.

Esperé que la solicitud a www.example.com fallara porque el certificado SSL del servidor de back-end es para server1.example.com . En realidad tiene éxito. No entiendo por qué funciona.

Si configuro el Nombre del host en los enlaces IIS a server1.example.com , la solicitud falla. Si lo dejo en blanco o lo configuro en www.ejemplo.com , la solicitud se realiza correctamente. No estoy seguro de por qué. No tiene sentido.

Entiendo que el F5 LB está actuando como el cliente en el apretón de manos entre él y el servidor backend. Pero mi entendimiento es que el F5 está enviando una solicitud para www.example.com (nombre de host) al servidor de back-end. El certificado SSL backend es para server1.example.com . Por lo tanto, la solicitud debe fallar porque el nombre de host que envía F5 no coincide con el nombre de host asociado con el certificado SSL del servidor de back-end. Es decir, www.example.com! = Server1.example.com .

Por favor, dime dónde estoy equivocado en mi lógica porque obviamente lo estoy. Simplemente no entiendo por qué funciona.

Gracias.

    
pregunta user3621633 21.10.2016 - 18:11
fuente

1 respuesta

1
  

Entiendo que el F5 LB está actuando como el cliente en el apretón de manos entre él y el servidor backend. Pero mi entendimiento es que el F5 está enviando una solicitud para www.example.com (nombre de host) al servidor backend. El certificado SSL de fondo es para server1.example.com. Por lo tanto, la solicitud debe fallar porque el nombre de host que envía F5 no coincide con el nombre de host asociado con el certificado SSL del servidor de back-end. Es decir, www.example.com! = Server1.example.com.

No estoy seguro de qué quiere decir con "la solicitud debe fallar". ¿Qué agente le fallaría? El servidor no valida el certificado SSL con el nombre de host; El cliente (en este caso, el LB) lo hace.

Debido a que es el LB el responsable de validar el certificado, puede averiguar de manera inteligente lo que está sucediendo y validarlo con el nombre de host correcto en lugar del nombre de host del nodo del servidor individual.

Así que aquí es aproximadamente lo que sucede:

  1. El navegador busca la dirección IP asociada con www.example.com
  2. El navegador establece una conexión TCP / IP a la dirección
  3. El navegador establece una conexión TLS a través de TCP / IP, recuperando así el certificado del LB (www.example.com)
  4. El navegador valida el Asunto del certificado contra el nombre de dominio enviado en el paso # 1 anterior; si no coinciden, obtienes una advertencia de phishing
  5. El navegador envía la carga HTTP a través de TCP / IP + TLS para cargar el equilibrador. Esta carga útil incluye un encabezado HTTP "Host: www.example.com"
  6. LB evalúa las reglas de equilibrio de carga y elige un servidor de servicios de fondo al que dirigir la solicitud. El resultado de esto es un nombre de servidor o una dirección IP, dependiendo de cómo haya configurado esto.
    • Si es un nombre de host, se usa solo para búsqueda de IP; se descarta inmediatamente después, porque el nombre del nodo del servidor no significa nada para el sistema en general.
    • Si se trata de una dirección IP, el LB solo usará eso. Tenga en cuenta que en esta configuración, el LB ni siquiera se entera de que el nombre del servidor de servicios de fondo es server1.example.com; de hecho, no tiene idea de cuál es su nombre.
  7. LB establece una conexión TCP / IP con el servidor de servicios de fondo
  8. LB establece la conexión TLS con el servidor de servicios de fondo, recuperando así el certificado del servidor de servicios de fondo (www.example.com)
  9. LB valida el tema del certificado de back-end contra el encabezado del host proporcionado por el cliente original, en el paso 5 (www.ejemplo.com)
  10. LB vuelve a cifrar la carga HTTP y la envía al servidor de back-end. Incluye el encabezado HTTP "Host: www.example.com" y también puede incluir encabezados adicionales como x-forwarded-for.

Nunca debe tener un encabezado de host que diga server1.example.com, ni tampoco se usará ese nombre de host para validar el certificado SSL.

    
respondido por el John Wu 22.10.2016 - 01:54
fuente

Lea otras preguntas en las etiquetas

Colas, seguimiento de nodos de retransmisión ¿Qué servidor es responsable de la "seguridad" cuando ASP.NET Core Kestrel está alojado detrás de IIS?