How can I configure Server SSL Profiles to connect to different URLs on the same server?

Hi,

We have a web server which has two sites published on it via a single Virtual Server on the BIG-IP: site1.domain.uk site2.domain.uk

Our security policy dictates that we must encrypt the connections between the user and the BIG-IP and between the BIG-IP and the web server.

We initially purchased a SAN certificate with site1.domain.uk and site2.domain.uk on it (site1.domain.uk is the default name). We have tried various methods of getting the end to end connectivity working with a user connecting using both URLs but all have failed.

Can anyone provide any guidance on how to achieve this?

ha_34906
Jun 24, 2015
Hello,

We had the same issue we had a single vip which teminated SSL at the LTM level but had to make two backend SSL connections to an HA-Proxy server so HA-Proxy would need to see the SSL call to a specific cert name. As you mentioned we created two separate Server SSL profiles each with differetn SNI and set one profile as default. No matter what we did the LTM only used the default profile SNI and ignored the secondary Server Profile's SNI when making the ltm to backend server SSL connection. Even in packet caputure we can see that it was only using default server's SNI only (we are running LTM 11.5.1. HF8). So that lead us to believe even though you can assign multiple server profiles with differetn SNI names, the LTM only uses the profile set as the default SNI and ignores the other profiles.

Our fix to this was to create a second VIP, map to the same backend servers and assign each vip with its own SNI profile. This is not an ideal setup if you are calling multiple certs or if you can't used multiple vips. But it worked for us and we didn't bother opening a case with F5 as I think you can not use multi-SNI calls on server side SSL calls.

Stanislas_Piro2
Cumulonimbus
Jun 16, 2015
Have a look to this POST : https://devcentral.f5.com/articles/ssl-profiles-part-7-server-name-indication

SNI allow the server to request target hostname before sending server certificate and answer with the good certificate.
osnetworks_6668
Nimbostratus
Jun 16, 2015
Thanks. We have tried many different combinations. We cant seem to get SNI to work between the BIG-IP and the server. In one of our attempts, we had two Server SSL profiles with site1 listed as the default SNI; connections to site1.domain.uk worked but connections to site2.domain.uk didnt. If we swapped the defaults so that site2 was the default SNI, that worked but site1 didn's so we're a bit stumped.
Hannes_Rapp
Nimbostratus
Jun 16, 2015
What client are you using? Not all web-browsers/OS.Systems support TLS SNI. Visit this page for testing - (ext link) https://sni.velox.ch/. If it reports "Great! Your client...sent the following TLS server name indication extension (RFC 6066) in its ClientHello..." means your client supports TLS SNI.
Stanislas_Piro2
Cumulonimbus
Jun 16, 2015
you must configure SNI on clientssl profile. and chose one clientssl as "Default SSL Profile for SNI" on each profile, fill "Server name" field with requested hostname in the browser.

which browser/OS do you use?
osnetworks_6668
Nimbostratus
Jun 16, 2015
We are using the latest Chrome build (43) and also IE10 and verifying against SNI validation websites checks out OK. I need to clarify what is required/possible in terms of client ssl profiles and server ssl profiles e.g. if the server ssl profiles are SNI based, must the client ssl profiles be SNI based also? Can we use SAN based client ssl profiles at the 'front' end between user and BIG-IP but use SNI based server SSL profiles at the 'back' end between the BIG-IP and server? Should we just use the default serverssl profile? We have tried many combinations and none of which have worked. The best we have gotten is the partial success as described in the OP.
osnetworks_6668
Nimbostratus
Jun 17, 2015
A bit more information now that we have done some packet captures... We set up the Virtual Server with 2 client SSL profiles, one for site1.domain.uk and the other for site2.domain.uk and have set site1.domain.uk as the “Default SSL Profile for SNI” (This is instead of using the SAN certificate described in the OP). We also used the default “serverssl” profile. In this instance, neither https://site1.domain.uk nor https://site2.domain.uk returned a page. The server is configured to only accept valid URLs and so a TCP reset was sent to the client from the server each time. Packet captures showed that the “Client Hello” message from the BIG-IP server did not specify a Server Name, hence the reset from the server.

We then replaced the “serverssl” profile with 2 separate server SSL profiles, one with site1.domain.uk as the “Server Name” and the other with site2.domain.uk as the “Server Name”. We also set the site1.domain.uk server ssl profile as “Default SSL Profile for SNI”. In this instance, we got a page back for https://site1.domain.uk but not for https://site2.domain.uk Instead we received a “400 Bad Request” when trying to access the site2 URL. Packet Captures show that the BIG-IP is still sending “site1.domain.uk” as the server name in the “Client Hello” even when trying to access the site2 URL. As a result, the server responds with the site1.domain.uk certificate. So when the BIG-IP sends the GET request for a page at site2, the server returns the 400 error. :stumped:
- k20
  Nimbostratus
  Dec 20, 2017
  Did you fix the issue? If so, please share your solution. I run into the same problem.
- Simon_Blakely
  Employee
  Dec 20, 2017
  K20,
  
  As noted further up the thread, you need to use an irule or Local Traffic Policy to deliberately select the appropriate serverside SSL profile to match the request.
  The Virtual server will automatically only select the server-side SSL profile that has the Default SNI flag set - if you need to select a different one, look at the host header and select the appropriate serverside SSL profile.
  Something like:
  when HTTP_REQUEST { set hostname [getfield [HTTP::host] ":" 1] } when SERVER_CONNECTED { switch -glob [string tolower [hostname]] { "site1.domain.uk" { SSL::profile site1.domain.uk-server } "site2.domain.uk" { SSL::profile site2.domain.uk-server } } }
- k20
  Nimbostratus
  Dec 20, 2017
  Tested yours, I got this error
  ¬†
  
  01070151:3: Rule [/Common/test_sni] error: /Common/test_sni:5: error: [undefined procedure: hostname][hostname]
  ¬†
  
  I tested this iRule, it works fine without any modification. https://devcentral.f5.com/s/articles/serverside-sni-injection-irule-968
  ¬†
ha_34906
Altostratus
Jun 24, 2015
Hello,

We had the same issue we had a single vip which teminated SSL at the LTM level but had to make two backend SSL connections to an HA-Proxy server so HA-Proxy would need to see the SSL call to a specific cert name. As you mentioned we created two separate Server SSL profiles each with differetn SNI and set one profile as default. No matter what we did the LTM only used the default profile SNI and ignored the secondary Server Profile's SNI when making the ltm to backend server SSL connection. Even in packet caputure we can see that it was only using default server's SNI only (we are running LTM 11.5.1. HF8). So that lead us to believe even though you can assign multiple server profiles with differetn SNI names, the LTM only uses the profile set as the default SNI and ignores the other profiles.

Our fix to this was to create a second VIP, map to the same backend servers and assign each vip with its own SNI profile. This is not an ideal setup if you are calling multiple certs or if you can't used multiple vips. But it worked for us and we didn't bother opening a case with F5 as I think you can not use multi-SNI calls on server side SSL calls.
- osnetworks_6668
  Nimbostratus
  Jun 25, 2015
  Thanks, this seems to confirm my suspicion that SNI is not supported on the server side. I have a call open with F5 so I will report back on that if they manage to resolve it.
- osnetworks_6668
  Nimbostratus
  Jul 02, 2015
  I got the following response from F5 support: When applying a serverside SNI profile, only the default profile is selected which replaces the host header of the incoming request. There is no hostname based serverside SNI selection (which is different from the clientside). The solution is to use an irule to select from the assigned serverside ssl profiles based on the contents of the hostname header. Something like this should work... when HTTP_REQUEST { set hostname [getfield [HTTP::host] ":" 1] } when SERVER_CONNECTED { switch -glob [string tolower [hostname]] { "site1.domain.uk" { SSL::profile site1.domain.uk-server } "site2.domain.uk" { SSL::profile site2.domain.uk-server } } }