In an explicit proxy setup, the client connects to the proxy server for outbound internet HTTPS requests, and then the proxy server establishes a separate TCP session to perform an SSL handshake with the SaaS platform server.

To intercept SSL connections, the proxy server replaces the certificate from the original server with a new certificate signed by an internal private-hosted root CA. Your browser must trust the internal private-hosted root CA to validate the certificate returned by the proxy server.

Install the HTTPS server certificate and the private key on the server-side SteelHead appliance for the first pair of SteelHead appliances to optimize SSL proxy connections. You cannot import the server certificate and the private key to the server-side SteelHead appliance because the proxy server dynamically issues the proxy certificate with the root CA.

You must generate a new set of the certificate and the private key (for proxy cert2) for each SaaS platform server to optimize the proxy connections. The certificate is signed by an internal private root CA; you must import the private root CA to the server-side SteelHead appliance.

For the second pair of SteelHead appliances optimizing using SteelHead SaaS, the Riverbed Cloud Portal manages the proxy certificates for SteelHead SaaS. You can use a customer-hosted CA as the proxy server root CA to sign the CSR that is generated from the Riverbed Cloud Portal for SaaS platform servers. Because the Riverbed Cloud Portal generates the SaaS platform server proxy CSR and private key, you cannot download the private key; therefore, you must ensure that the new set of proxy certificates are signed.

In Figure: Riverbed Cloud Portal managing proxy certificate, the Akamai Cloud SteelHead appliance returns the proxy cert3 for the second optimization phase to the proxy server (client).

The deployment described here assumes that the same internal private root CA installed on the proxy server is the root CA that signs proxy certificates for these appliances: