HTTPS rewrite to HTTP.

You can do this, but the F5 won't have the correct certificate for the site the client(s) are trying to reach, and this will cause browser warnings and in some cases, the browser will refuse to go to the site. For users that push through the warnings, you could then return a redirect to the original host via HTTP using the iRule/HTTP Class/Local Traffic Filter mechanisms described on DevCentral.

If you don't want the browser warnings and if you control the endpoints, you could create a root certificate, push that out to all browser caches, and then use said root certificate to sign a wildcard certificate that you use to handle all client SSL sessions. Since the signing certificate is in the browser cache, no warnings, then you send the redirect.

Keep in mind that the solution I am describing is very indiscriminate - it's going to affect every SSL connection attempt. When the CTO sees that their online banking traffic is affected, they might make you rip it all out.

Hope this helps.

Answer=

You can inspect the initial Request and append the needed URI to the request via irule :)

But you have to config client ssl profile to decrypt https packet before customize them. Correct me if I'm wrong :D

If I understand Archie correctly, he's talking about a forward proxy function - internal users accessing external content through a content filter that is load balanced by the BIG-IP. You could indeed implement a wildcard certificate in a client SSL profile, but that would only apply to some (very small) subset of external hosts given that a wildcard CANNOT exist for a one-level deep TLD (ex. *.com).

An option here would be the Forward SSL Proxy feature new in version 11.3. This feature allows you to put a local (subordinate) certifying authority (CA) certificate on the BIG-IP that will, on-the-fly, issue local versions of the remote site's server certificates. The local client's must be configured to trust this CA certificate to avoid certificate errors. This would allow you to decrypt and inspect the outgoing traffic. More information can be found here:

Manual Chapter: Implementing SSL Forward Proxy on a Single BIG-IP System

Thanks for everyones input on this. I can't go into specifics but deploying SSL / Inspecting SSL in our deployment is a bit of a minefield.

After reading what everyone is saying here, it looked all too difficult. Regardless of the chosen path some kind of Cert deployment would be needed.

To get around this, one thing EVERYONE must use in our organisation is DNS, so I've placed an RPZ in our DNS solution to make sure ANY request going to Google is sent to the nosslsearch.google.com VIP of Google. Works very well.

Thanks again everyone who answered.