2

I have an F5 load balancer and a backend server. Load balancer is www.example.com. Backend server is server1.example.com. I have the F5 load balancer with SSL Profile (client) and SSL Profile (server) enabled and SSL certs on the load balancer and backend server. So it looks like this:

Client (laptop) --> HTTPS/SSL --> F5 Load Balancer (www.example.com) --> HTTPS/SSL --> Backend server (server1.example.com)

The backend server is running Windows 2012/IIS 8.5. In the bindings, the Host Name field is blank.

I expected a request to www.example.com to fail because the backend server SSL Cert is for server1.example.com. It actually succeeds. I don't understand why it works.

If I set the Host Name in the IIS bindings to server1.example.com, the request does fail. If i leave it blank or set it to www.example.com, the request succeeds. Not sure why. Doesn't make sense.

I understand the F5 LB is acting as the client in the handshake between itself and the backend server. But my understanding is the F5 is sending a request for www.example.com (host name) to the backend server. The backend SSL cert is for server1.example.com. Therefore, the request should fail because the host name being sent by the F5 does not match the host name associated with the backend server SSL cert. That is, www.example.com != server1.example.com.

Please tell me where I am wrong in my logic because I obviously am. I just don't understand why it works.

Thank you.

Improve this question
7
  • (1) Why do you have a load balancer if you have a single server? (2) Why the load balancer cannot simply work as a reverse proxy and just pass the TCP stream to the server? (i.e. the load balancer should not care about what passes through it)
    – grochmal
    Oct 21, 2016 at 16:41
  • Hi. Thank you for your response. I don't want to get into the why. The above is a simplistic example. There are more backend servers the LB manages. But my point was why does the SSL handshake between the LB and backend server work with an SSL cert with one DNS name (www.example.com) and an SSL cert with a different DNS name (server1.example.com)? My expectation was it would fail but it doesn't.
    – user3621633
    Oct 21, 2016 at 16:58
  • It doesn't, do you actually have any certs on the load balancer? I believe that you do not.
    – grochmal
    Oct 21, 2016 at 17:00
  • Yes. There is an SSL cert on the LB. I don't think the LB is sending a client SSL cert to the backend server, however. It's just encrypting the traffic outbound to the backend server.
    – user3621633
    Oct 21, 2016 at 17:03
  • Hmm... you have an interesting configuration there :-) . You should give us the output of openssl x509 -in <cert> -text (and modify the output to not show private data, but I guess that the most important part should be Subject: and X509v3 Subject Alternative Name:). If the server is capable of accepting a challenge for www.example.com its cert must have that as the main or alternative name.
    – grochmal
    Oct 21, 2016 at 17:09

1 Answer 1

Reset to default
1

I understand the F5 LB is acting as the client in the handshake between itself and the backend server. But my understanding is the F5 is sending a request for www.example.com (host name) to the backend server. The backend SSL cert is for server1.example.com. Therefore, the request should fail because the host name being sent by the F5 does not match the host name associated with the backend server SSL cert. That is, www.example.com != server1.example.com.

I am not sure what you mean by "the request should fail." What agent would fail it? The server does not validate the SSL cert against the host name; the client (in this case, the LB) does.

Because it is the LB that is responsible for validating the cert, it can intelligently figure out what is going on and validate against the correct host name rather than the host name of the individual server node.

So here is approximately what happens:

  1. Browser looks up the IP address associated with www.example.com
  2. Browser establishes a TCP/IP connection to the address
  3. Browser establishes a TLS connection over TCP/IP, thereby retrieving the cert from the LB (www.example.com)
  4. Browser validates the Subject of the cert against the domain name submitted in step #1 above; if they don't match, you get a phishing warning
  5. Browser sends HTTP payload over TCP/IP+TLS to load balancer. This payload includes an HTTP header "Host: www.example.com"
  6. LB evaluates load balancing rules and picks a back end server to which to direct the request. The output of this is either a server name or IP address, depending on how you have this set up.
    • If it is a host name, it is used only for IP lookup; it is discarded immediately afterwards, because the name of the server node doesn't mean anything to the system overall.
    • If it is an IP address, the LB will just use that. Notice that in this setup, the LB never even learns that the name of the back end server is server1.example.com; in fact it has no idea what its name is.
  7. LB establishes TCP/IP connection to back end server
  8. LB establishes TLS connection to back end server, thereby retrieving the cert from the back end server (www.example.com)
  9. LB validates the subject of the back end cert against the host header provided by the original client, in step 5 (www.example.com)
  10. LB re-encrypts the HTTP payload and submits to back end server. It includes the HTTP header "Host: www.example.com" and may also include additional headers such as x-forwarded-for.

You should never have a host header that says server1.example.com, nor will that host name ever be used for validation of the SSL certificate.

Improve this answer
3
  • Wow. I sincerely appreciate and DETAILED explanation. Thank you! I do have a question. For Step 8, you said LB retrieves the cert from the backend server (www.example.com). The backend SSL cert, in my configuration, is server1.example.com. There is no www.example.com SSL Cert binded to the IIS website on server1. The www.example.com SSL cert is only on the LB. So, I'm confused how the LB can retrieve an SSL cert that doesn't exist on server1. Thank you again.
    – user3621633
    Oct 22, 2016 at 1:52
  • I left out a lot of details. There are so many options! On the F5 you can configure the SSL server profile with an "authenticate name" to match the subject of the back end SSL certificate. You can set this to www.example.com, server1.example.com, or whateveryouwant.example.com as long as it matches the cert-- it doesn't have to match the actual domain name of the back end host.
    – John Wu
    Oct 22, 2016 at 3:51
  • Ohh, I see! Oh, Wow. That's interesting. That's similar to the option in F5 LB to not perform SSL validation. But from what you're saying, I could have an expired SSL cert binded to the backend server and LB won't care. The request will still go through, as long as the host header from the original quest matches the subjecf of the back end ssl cert (Step 9). Wow. Learned so much here! Thank you!!! This is EXACTLY what I needed! It all makes sense. Your feedback and wisdom are most appreciated. I'm very, very thankful!
    – user3621633
    Oct 22, 2016 at 5:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .