Handling Client Certificates

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.

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.

I apologize. I thought you were just attempting normal SSL Off-Load.

 

 

Here are several discussion threads of using iRules to pass Client Certificates through to the Application Server.

 

 

http://devcentral.f5.com/Forums/tabid/1082223/asg/50/showtab/groupforums/aff/5/aft/29075/afv/topic/Default.aspx

 

http://devcentral.f5.com/Forums/tabid/1082223/asg/50/showtab/groupforums/afv/topic/aff/5/aft/6260/Default.aspx

 

 

Guide using Firepass:

 

http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/141/Configuring-Client-Certificate-Passwordless-Authentication-on-FirePass.aspx

So there's no way to map an incoming client certificate to an "internal" Big-IP client certificate?

 

The client authentication certificate, that Big-IP will present to the back server is always the one specified in the Server SSL profile?

 

If it can't be done through configuration, can it be done via iRules?

 

 

If you had one server SSL profile per client cert you wanted LTM to present to the pool member, you could potentially use SSL::profile to select the profile.

 

 

Aaron

Can't believe I'm replying to such an ancient thread but the landscape has changed...

 

F5 now sports a mode called "ProxySSL" where it uses the same key+cert that the back-end server uses. You can then use this mode to let the client authenticate all the way to the back-end server. There is also a special sub-mode called "ProxySSL Passthrough".

 

There is also a mode called "SplitSSL" which is similar and may also do what you need.