Posted By Michael Yates on 06/18/2010 12:36 PM
You have the options correct on what the BigIP LTM can provide.
However, the SSL Off-Load (Client->SSL->Big-IP->SSL->Application Server) is for the most part transparent to the client and the application. It also gives you the opportunity to do traffic inspections, modifications, and more granular traffic management.
Either way, since SSL is terminated at Big-IP, there's no way for the real client certificate to travel all the way to the application server, unless it is injected by an iRule as a custom HTTP header. Which means that the application has to be aware (by a config option for example) and act differently, based upon whether or not there's Big-IP in the middle.
Am I correct so far?
The client doesn't have an SSL Certificate. The Client has an "expectation" to be talking to a specific website, which is why you get an error if the presented SSL Certificate does not match the actual website.
Another question - let's say we have 2.2 Client->SSL->Big-IP->SSL->Application Server
Does Big-IP provide an option to map the certificate coming from a client to another (client) certificate the Big-IP is to use (when acting as a client) to establish SSL connection to the application server?
The option that you are looking for is not necessary. In this scenario: Client->SSL->Big-IP->SSL->Application Server
Client – attempts to access https://www.website.com
BigIP – presents CA Signed SSL Certificate for www.website.com
Client validates that this is a CA (Certificate Authority – Verisign, Entrust, etc…) Signed Certificate. If yes, then trust is established.
BigIP can now run any iRules against the traffic.
BigIP – selects application server (through whatever Load Balancing method is configured on the Virtual Server) and contacts the server in the exact same way the Client contacted the BigIP (because the BigIP is the Client to the Application Server). Biggest difference here is that the BigIP can be configured to validate the SSL Certificate or ignore the validation and just accept it (see Local Traffic -> Profiles -> SSL -> Server and select a serverssl profile under the “Server Authentication settings).
Application Server – treats the BigIP as the client and response normally.
Other than the SSL-Offload none of the payload from the client is altered (unless you do it with an iRule).
Hope this helps.
Thanks Michael.
I think you missed the point though - in my case the client must posses and present a valid client (authentication) certificate to the server. In other words - the connection is mutually authenticated on both sides of the SSL channel. That's a standard feature supported by every web server and it's the very core of my question (what are the options in BigIP for handling client authentication certificates).
The problem occurs when you put BigIP in the middle and set it to terminate the SSL. Then even if you set it to initiate an SSL connection (with a client certificate) to the back server, it cannot simply "impersonate" the client (because it doesn't have the private keys for the client authentication certificate supplied by the client and can only send another client authentication certificate that it actually owns (as in has the private keys for).
The back server, expecting client authentication certificate instead of the original certificate, supplied by the client, will receive a BigIP certificate instead.