Forum Discussion
NimbostratusSSL Termination issue
Hi,
Hoping someone can help?
We have a number of webservers being served by the F5. The SSL Certificate is being terminated at the F5 and then re-encrypted with the same certificate onto the webservers (Web Servers are on HTTPS).
Originally we had the F5 just doing the SSL pass through and the webservers were ne the certificate, which worked fine. Now that we are terminating and re-encrypting on the F5, some of the functionality as stopped working. The issue we are having is that we use UniPass to authenticate users rather than username password, when you hit the webpage you are prompted to select the Unipass certificate. The prompt is no longer appearing and it looks like its because the webpage is unable to read from the clients certificate store?
Hope this makes sense?
Help!
TommmyQ
3 Replies
- Kevin_Stewart
Employee
As I understand it, the Unipass identity is a client certificate, and client certificates generally get sent during the SSL handshake phase. The issue with that you're doing is based on the way this "mutual authentication" works with respect to that handshake. After the server requests the client's certificate, the client sends that certificate and a separate "Certificate Verify" message. This message contains a digital signature which is signed with the client's private key. Therefore, as the BIG-IP would not have access to the client's private key, you cannot terminate and re-encrypt SSL traffic between the client and server and still be able to pass that client certificate to the server.
There are a few ways to handle this limitation:
-
Authenticate the certificate at the BIG-IP and then pass some other form of authentication to the server. The Access Policy Manager module provides pretty robust ways to handle this.
-
ProxySSL - an LTM function that provides an "SSL man-in-the-middle" for inbound traffic. This allows the BIG-IP to passively decrypt the traffic while still allowing the client and server to handshake directly. ProxySSL, as with all SSL man-in-the-middle, or "passive SSL" techniques, requires 1) access to the server's private key and 2) an RSA-based key exchange, which is not perfect forward secret. This is getting harder to do as more clients deprecate RSA key exchange crypto.
-
SSL tunnel - where you do not terminate and re-encrypt the SSL at the BIG-IP. This obviously limits the effectiveness of the proxy.
-
- Kevin_Stewart
If I was to have the webservers using (HTTP) and don't re-encrypt the connect, so basically SSL offload would this get round the issue?
Well, yes. But then you wouldn't be providing any authentication to the backend servers.
- Kevin_Stewart
Assuming the UniPass is a typical X.509-based client certificate, it gets handed to the server side (the BIG-IP in this case) during the SSL handshake. Neither that certificate information, nor the certificate itself, is forwarded on to the backend servers. Option 1 in my previous post talked about using a different authentication scheme on the server side. For example, with client side client cert (PKI), APM can do Kerberos on the server side. I'm guessing the client doesn't also present a username and password in this transaction, so you couldn't do something like HTTP Basic or NTLM on the server side (which require a password). You could also simply configure the application to consume an HTTP header sent from the BIG-IP, a header that might contain information from the client certificate.
