Certificates implementation in "SSL forward proxy client and server authentication" scenario.

I understand your scenario to be a reverse proxy setup. You can read more here and determine which applies to your scenario:

http://stackoverflow.com/questions/224664/difference-between-proxy-server-and-reverse-proxy-server

Simply put, a reverse proxy is where an unlimited number of external clients access a limited set of internal resources. This would be the scenario where remote (Internet) users are accessing your local applications. A forward proxy is where a limited set of internal clients access an unlimited set of external resources. This would be a scenario where you'd want to proxy and control the Internet access of your local user community. What you've alluded to has been in the realm of a reverse proxy configuration, so no forward proxy SSL settings are necessary.

My understanding is that in a reverse-proxy scenario, the "verint.ext.videotron.com" certificate would be located on both backend servers (snverapp1 & snverapp3) servers. This is not possible because on the applications residing on those backend servers. So, in my case, the BIG-IP must hold the "verint.ext.videotron.com" certificate and load balance traffic between the 2 backend servers using SSL. This is why my perception is that I should use forward proxy. This is why I applied the "SSL forward proxy client and server authentication" procedure and I don't understand why it is not working. The difference I noticed between the 11.3.0 and 11.5.0 reside in the "Server SSL forward profile" section. Using Google Chrome, I have a more verbose response where the error shows: Error type : Malformed certificate Object : snverapp3.ext.videotron.com Issuer : testverint.ext.videotron.com

If this is in fact a reverse proxy environment (external users accessing internal resources) then you DO NOT configure any forward proxy SSL settings in the SSL profiles. This is strictly for internal clients accessing remote (Internet) services. So given this, your client SSL profile needs to have the external certificate and key (verint.ext.videotron.com) applied. This should be all that you need in the client SSL profile. Again, no forward proxy SSL settings here. The client SSL profile is responsible for the client-to-F5 SSL session. To re-encrypt to the backend servers, you also apply a server SSL profile to the VIP. This profile maintains the client side of the server side SSL session. In most cases you don't have to do anything to this profile, nor does it matter what certificates you use on the servers themselves. The server SSL profile will ignore any certificate subject and/or trust mismatches.

So if I understand correctly, I create a client SSL profile configured with the "verint.ext.videotron.com" certificate which I associate in the virtual server's "SSL Profile (Client). Then I associate the default "serverssl" SSL profile in the "Server Profile (Server)" field of the virtual server? No need to use backend server's certificates?

That is correct. Unless there's any kind of client certificate based authentication occurring, these should be the only SSL profile configurations you need.

Attaching to the topic, what if i have requirement to make client auth on the server side ? How to proceed with this correctly ?

If you are referring to the server authenticating the client by certificate, then you'll need to use the Proxy SSL feature to preserve the client certificate for that authentication.

http://support.f5.com/kb/en-us/solutions/public/13000/300/sol13385.html

Attaching to the topic, what if i have requirement to make client auth on the server side ? How to proceed with this correctly ?

Do you mean pass the client certificate to the server? If so, you have two options:

1. Don't offload SSL - simply pass the SSL layer data through the proxy. You cannot see any of the layer 7 traffic, so there's a lot of really cool capabilities that you'll lose by doing this, but it's an option nonetheless.

    

2. ProxySSL - this is an SSL man-in-the-middle function that allows a BIG-IP to "see" decrypted payload between a client and server, without technically being part of any SSL handshakes. There is some complexity to this approach, and frankly it doesn't work in every environment and for every set of ciphers, but when it does work, you can see and affect the layer 7 payload.

    

Simply put, when a client and server engage in mutual SSL authentication, the client will first digitally sign its certificate before sending it to the server. A digital signature is basically a hash of some piece of data that is then encrypted with the sender's private key. The recipient generates a new hash of the sent data, decrypts the digital signature with the sender's public key (in the certificate) and then compares the two values. If they are the same, then the recipient knows that 1) the sender is who they say they are by virtue of private key possession, and 2) the data has not been altered in transit. The certificate itself is also used to verify cryptographic "trust" between the client (or server) and a common trusted "anchor". It is for this reason that you cannot terminate SSL at the proxy and get the client's certificate to the server - because 1) terminating the SSL would destroy the digital signature, 2) and only the client would have a copy of the private key needed to generate a new one.

Ok - i will try to clarify the problem (solution is in design phase so all recommendations are appreciated). 1 - there are 2 clients that will be connecting to F5 (HTTP is planned here) 2 - F5 has to connect to 1 server which requires client auth As i understand it correctly i can make 1 VIP with server SSL Profile (when there is no client auth required - this is ok) - but here i have the requirement to authenticate client (in this case F5) to the server. Any ideas how to solve this ?