Client Authentication on server side ssl

how on the server-side-ssl, we can make the certificate based authentication.

In short, you cannot. I won't dive too much into the technical details here other than to say that in order for an entity to authenticate with a client certificate, it must have possession of the private key (used to digitally sign one of the messages in this "mutual PKI" sequence). The client digitally signs information going to the F5, so that works. But the F5 wouldn't have access to the client's private key, so there'd be no way for it to perform client certificate authentication to the server on the client's behalf.

You have a few options here:

1. Don't process SSL on the F5 - the crudest and simplest option that effectively turns your BIG-IP into a blind layer 4 load balancer.

    

2. Enable ProxySSL - an option that provides an SSL "man-in-the-middle" functionality, but requires 1) the F5 to have a copy of the server's private key, and 2) that you ONLY perform non-ephemeral (non-perfect forward secret) RSA key echanges during the SSL handshake. This is still an option, but clients and servers are starting to deprecate the use of RSA for key exchange.

    

3. Perform some other kind of authentication on the server side - this is exactly the sort of thing APM is great at. Take information from the client side certificate exchange and roll it into some other authentication scheme, like Kerberos.

    

If we're still talking about client certificate authentication, then no. Mutual PKI authentication is a function of the SSL handshake. So for the server to be able to consume the client's certificate, they must perform a direct SSL handshake, which means you cannot decrypt and re-encrypt in the middle. The F5 is then blind to the application traffic.

I would add that this is a pretty common question and is really a limitation imposed by SSL itself. Ultimately if you need to do certificate-based authentication and still be able to do something intelligent with the traffic at a proxy layer, the proxy has to do something different on the server side. Since you're certificate likely doesn't contain a password, you wouldn't generally be able to do HTTP Basic or NTLM on the server side (which require a password), but you can do Kerberos. You could also consider sending the credential information to the servers as HTTP headers (encrypted of course). In any case, you would have to change the way the servers consume client credential information.

https://support.f5.com/kb/en-us/solutions/public/13000/300/sol13385.html This is exactly what i am trying to configure and its possible.

Yes, it's possible, but keep in mind that ProxySSL, and really ANY SSL man-in-the-middle (MITM) technology (some call it "passive SSL", or "bump-in-the-wire SSL") suffers from the same two very important requirements:

1. Knowledge of the server's private key - it's probably also worth noting that this requirement alone makes it only useful for inbound (reverse proxy) traffic. You would never have the private key of servers on the Internet.

    

2. A non-ephemeral RSA-based key exchange (handshake) - you can pretty much throw perfect forward secrecy and any Diffie-Hellman key agreements out the window. They won't work with an SSL man-in-the-middle technique. Aside from being non-perfect forward secret, the RSA key exchange is quickly being deprecated in the industry and there's word that the upcoming TLSv1.3 won't include RSA key exchange at all. Ultimately SSL MITM (ProxySSL and others) requires that the client and server handshake directly, so if they don't handshake with RSA, and you can't make them handshake with RSA (because neither offer or support RSA), then your MITM product won't work. You have a little time left, but that window is closing.

    

Hey,Could someone post what is recommended approach from F5 vendor. These are our requirements for establishing a ssl mutual auth.

Users have client certificate for authentication. backend Server is running with https when user connects on https to the server, server asks for client certificate. Server validates client certificate and allows user to connect if cert is validated.

we want to route few URI paths on SSL and few of them on Non-SSL for same back end servers on port 80 & 443.