Rule to assign different SSL Keys based on Host Header

The question is somewhat ambiguous.

 

 

Do you mean the SSL key/certificate pair based on the HTTP host header in a corresponding HTTP plain-text request on the client side that then gets redirected to an SSL virtual server, or a client-side SSL certificate used to handshake with a server in the re-encryption case?

 

 

Please let us know what you're trying to do, and let's see if we can work through it.

 

Basically what I have is a pool of web servers hosting 2 web sites on the same IP. Each web site uses a different domain name, but share a common Virtual Server. Is it possible to assign 2 SSL key/certificate pairs to 1 Virtual Server?

There's no way to do this yet. However, we have an open CR for this, CR40685, we've looked at a prototype for this. If you have a support contract, perhaps it will benefit you to request scheduling of this CR.

This shouldn't be possible. It's a limitation of how HTTPS works.

 

 

First, the client connects to the server on port 443. SSL is negotiated. Then the client sends the HTTP GET/HEAD/etc, and the Host: header.

 

 

The SSL cert is presented *BEFORE* the Host: header is sent. The server *MUST* send a cert before it knows which one it should choose. Unless v9 includes a mind-reading module, this shouldn't be possible.

 

 

I could kick the SSL developers from not allowing a 'server identification suggestion' from the client as part of the SSL negotiation.

Actually, interestingly enough it's very much possible with a little trickery. Consider the case where 10.1.2.3 maps to "internal-hr.example.com" for the HR subnet of your intranet, and that same address maps to "internal-legal.example.com" for the legal dept subnet of your company. One should be able to decide which certificate to present based on L4 decisions (source IP for example.)

 

 

Or persistence (say someone visits a VIP from which we know we always issue a redirect to a secured site, we can drop a short-lived persistence entry in the table so that we can lookup the persistence record and know which certificate to send.)

 

 

Sure, in traditional SSL deployments, this wouldn't be possible. But we pride BIG-IP on being a pretty smart-and-nifty networking device :-).

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.