Forum Discussion
jforaker
Nimbostratus
NimbostratusClient SSL profiles using SNI not able to use the subject alternative name
We have a clientssl profile using a *.domain.com wildcard SSL certificate. This profile is set as the default for SNI. We also have specific clientssl profiles using the application specific SSL certificate. The application specific certs have their subject as www.application.com with the subject alternative name with application.com. There may also be several other SAN listed depending on the web app.
In testing everything works great when accessing the site via https://www.application.com. However when using https://application.com we receive a cert error and the *.domain.com wildcard SSL certificate is used. This is the same for any domain listed as a SAN.
My main question is can SNI use subject alternative names? My testing indicates no, but I wanted to put this out to the group.
Here is my sanitized config:
ltm profile client-ssl domain.com_wildcard {
app-service none
cert domain.com_wildcard.crt
chain ComodoCA.crt
defaults-from clientssl
key domain.com_wildcard.key
sni-default true
}
ltm profile client-ssl prod-www_application_com {
app-service none
cert prod-www_application_com.crt
chain prod-www_application_com.intermediate.ca.crt
key prod-www_application_com.key
}
ltm virtual vs-x.x.x.x_443 {
destination x.x.x.x:https
ip-protocol tcp
mask 255.255.255.255
pool site-x.x.x.x_443
profiles {
http-x-forward { }
domain.com_wildcard {
context clientside
}
prod-www_application_com {
context clientside
}
serverssl-insecure-compatible {
context serverside
}
tcp { }
websecurity { }
}
source 0.0.0.0/0
source-address-translation {
pool snat_pool
type snat
}
vs-index 2539
}
- Kevin_Stewart
Employee
SNI doesn't really care about what's in the certificate, but rather what you've defined in the Server Name attribute of the client SSL profile. I haven't tried this, but thinking you could create a separate client SSL profile for each SAN name that isn't covered by the wildcard, using the same cert/key, and then apply all of those to the VIP.
jforakerKevin thanks for this. I did not notice the Server Name in the profile. As a test I configured this entry with a wildcard for the certificate domain: *.application.com.
This worked with one of our certs that have multiple SAN entries but they are all in the same domain:
preview.application.com
pre-pub.application.comIs there any way to have multiple domains in the server name field of the clientssl profile to cover multiple domains?
preview.application.com
pre-pub.application.com
preview.differentapplication.com
pre-pub.differentapplication.comIf not then the only option would be as you stated, a clientssl profile for each SAN name.
- Kevin_Stewart
You can't put multiple values in this field, so you'd need to create a separate profile for each SAN name.
Thomas_50423Hi Jeff,
I had to deal with SSL configuration on F5 some time ago. I didn't especially work on SNI but I think you can declare multiple domains (including wildcards) in the "Server Name" field of your client ssl profile (cf. http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-1-0/ltm_ssl_profiles.html). Simply separate each entry by a comma, let's say something like this in your case :
Server Name "preview.application.com,pre-pub.application.com,preview.differentapplication.com,pre-pub.differentapplication.com"
Or using wildcards :
Server Name "*.application.com,*.differentapplication.com"
Note that multiple domain names is only applicable for client ssl profiles and not server ssl profiles
Let us know about this configuration if you test it
Cheers
crraymond_14666It doesn't seem to accept commas in 11.5.2
The 11.6.1 release notes also indicate the default for the server name field is now the SAN. Formerly it was the common name.
- Kevin_Stewart
But again, what really matters here is what's in the Server Name field of the client SSL profile. This is what the F5 matches the Client Hello SNI against. It's true that browsers are starting to require a SAN value in server certificates (ex. Chrome 58), but that's irrespective of the SNI-profile match.
