Forum Discussion

EricZ's avatar
EricZ
Icon for Nimbostratus rankNimbostratus
Jun 13, 2014

Multiple SSL profiles/certs for network virtual servers

F5 has repeatedly recommended to decrease our object count due to excessive system load, which we have by migrating hundreds of /32 virtual servers into only several network virtual servers. Currently, /24 (or IPv6 /64) network virtuals servers point to our port 443 pools. We would like to now start off loading SSL on our Viprion's. I'm not clear how multiple SSL profiles/certs work with network virtual servers, of if it works at all? Is our only option here going back to single /32 virtual servers for each SSL profile?

 

2 Replies

  • Hi!

     

    You could select ssl profile with an iRule depending on virtual ip using SSL::profile:

     

    https://devcentral.f5.com/wiki/iRules.SSL__profile.ashx

     

    If you already have performance problems you might want to consider a switch for up to 100 objects and a data group list for over 100 objects. Personally I'd go with the data group list if possible.

     

    /Patrik

     

  • I'm not sure if any of your sites use a wildcard or UCC cert but what you can do is create one profile per certificate, instead of one for every virtual server, but this isn't always possible depending on your URLs. We had problems with people using the iApp for basic load balancing, the problem with it was that it generated new profiles for every virtual server and all of those profiles were the exact same as the default! It also created a new SSL Client profile for every website too, since most of the websites we were creating were sub-domains this didn't make much sense, especially with the fact we already owned a wildcard cert. This lead to tons of junk objects in our F5 that provided no real value. One of the first things I did was organize our SSL certs into profiles that I could reuse across different web servers. We went from having around 50 SSL Client profiles to 7.

     

    With the other profiles like HTTP, compression, etc. we just changed those all back to default since none of those profiles had any settings that were different than the default.