Forum Discussion

osnetworks_6668's avatar
osnetworks_6668
Icon for Nimbostratus rankNimbostratus
Jun 16, 2015

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...
application delivery
LTM
san
sni
ssl
  • ha_34906's avatar
    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.

     

osnetworks_6668's avatar
osnetworks_6668
Icon for Nimbostratus rankNimbostratus

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:

 

Simon_Blakely's avatar
Simon_Blakely
Icon for Employee rankEmployee
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 
         } 
     } 
}