Forum Discussion

Piotr_Lewandows's avatar
Piotr_Lewandows
Icon for Altostratus rankAltostratus
May 15, 2017

SNI for serverssl profile

Hi,

 

I have situation like that:

 

  • VS with two clientssl profiles
  • https1.test.com - SNI set to https1.test.com, Default SSL Profile for SNI checked
  • https2.test.com- SNI set to https2.test.com
  • and two serverssl profiles
  • server1.test.com - SNI set to server1.test.com, Default SSL Profile for SNI checked
  • server2.test.com - SNI set to server2.test.com
  • Server with two virtual hosts
  • server1.test.com - with certificate for server1.test.com
  • server2.test.com - with certificate for server2.test.com

Is there any way to configure VS so when request comes with SNI https1.test.com serverssl profile with SNI server1.test.com and when request comes with SNI https2.test.com serverssl profile with SNI server2.test.com is used?

 

Can it be somehow done in iRule? Maybe it's possible to use one serverssl profile and then change SNI send to server depending on SNI received from client?

 

Any easier way to resolve this?

 

A bit separate question - how BIG-IP verifies that presented server certificate is signed by CAs trusted by BIG-IP? By setting in serverssl Server Authentication:

 

  • Server Certificate: require
  • Authenticate Name: server FQDN (or rather content of CN filed from certificate)
  • Trusted Certificate Authorities: chain file with Root CA and all Intermediates

Seems to be working but I am not sure if this is correct way?

 

Not sure why when chain file contains only Root CA cert and server cert is signed by Intermediate two levels above (Root CA -> Intermediate 1 -> Intermediate 2 -> server cert) connection is still working.

 

Piotr

 

application delivery
certificate
devops
LTM
server authentication
sni
  • dragonflymr's avatar
    dragonflymr
    Icon for Cirrostratus rankCirrostratus
    May 16, 2017

    Hi,

    In relation to authentication of backed servers by BIG-IP (via serverssl Server Authentication config). I wonder if below setup is OK and can be used instead of using wildcard certificate on backend server.

    Scenario:

    • VS accepting request for https.test.com and https1.test.com
    • Two serverssl profiles:
      • lamp4-110.test.com_srv - attached to VS with settings:
        • Server Name: lamp4-110.test.com
        • Server Certificate: required
        • Authenticate Name: lamp4-110.test.com
        • Trusted Certificate Authorities: lamp_chain
      • lamp4-110-2.test.com_srv - not attached to VS with settings as previous except:
        • Server Name: lamp4-110-2.test.com
        • Authenticate Name: lamp4-110-2.test.com
    • iRule as below

    when HTTP_REQUEST {

    if { [getfield [getfield [HTTP::host] ":" 1] "." 1] eq "https" } {

    set sni_value "lamp4-110.test.com"

} else {

    set sni_value "lamp4-110-2.test.com"

}

    HTTP::header replace Host $sni_value

}
when SERVER_CONNECTED {

SSL::profile ${sni_value}_srv
}

    In SSL::profile description there is note:

    Warning: If you choose an SSL profile with a different key/cert/chain/ca-file from the SSL profile configured under the VS, the cert/key/ca-file must be reloaded, which is very time consuming (about half a second), degrading the SSL TPS performance drastically.

    I assume that it is not related to above setup as it's serverssl profile and Trusted Certificate Authorities is using exactly the same chain file.

    Any better ways to achieve backend server authentication using FQDN based certs (instead of wildcard)?

    Piotr