Forum Discussion

jforaker's avatar
jforaker
Icon for Nimbostratus rankNimbostratus
Mar 10, 2014

Client 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
}

7 Replies

  • 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.

     

  • Kevin 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.com

     

    Is 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.com

     

     

    If not then the only option would be as you stated, a clientssl profile for each SAN name.

     

  • You can't put multiple values in this field, so you'd need to create a separate profile for each SAN name.

     

  • Hi 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

     

    • Michael_Voight_'s avatar
      Michael_Voight_
      Historic F5 Account

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

      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.