Rule to assign different SSL Keys based on Host Header

One last thing: I'll point out that there are indeed caveats with this approach. As bri correctly notes, there's no way you can get to the Host: header within the SSL encapsulation prior to the handshake, so you're somewhat relegated to using either <= L4 rules to pick the SSL certificate, or persistence.

 

 

Persistence sounds like a good idea at first blush, but this also has its problems when dealing with megaproxies and multiple addresses (sure you could hack something together than looked at the contiguity of client port allocations, but this would just be... evil.)

 

 

But the point remains that using BIG-IP, you can knit together various decisions and information across sessions to determine what kind of handshake to initiate at SSL. This type of flexibility is inherent in the design of the product, and we make it available to our customers and power-users.