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

The problem is sort of a paradox. You need to known when to decrypt and when not to decrypt based on the request, but you can't know that without decrypting first. There are a few less-than-optimal options:

1. If you can base all decisions on IP addresses (OSI layer 4), then you could either enable/disable SSL based on client source or have two separate destination VIPs with different SSL characteristics.

    

2. The TLS protocol offers an attribute in unencrypted handshake data, the "servername" value, that can be used to make routing decisions. This gets tricky because 1) beyond the handshake you have to maintain some form of persistence, and 2) not every client will support TLS.

    

I would also add, as I mentioned before, that not offloading the SSL at the proxy will put you at some disadvantage. SSL throughput on a BIG-IP device will almost always be MUCH higher than that of a commodity server, offloading SSL gives you the ability to enforce stronger client authentication and cipher control than you can usually get from a typical web server, and without access to the unencrypted HTTP payload at the proxy, you lose HTTP-based iRules, layer 7 optimization, cookie persistence, etc. Perhaps a better approach is to think about the many ways the F5 device can be used to proxy authentication instead of pass it through.