Configuring SSL Optimization on SteelHeads

This section describes how to deploy SSL optimization on SteelHeads and provides common configuration examples. This section includes the following topics:

You need the following SSL components to deploy SSL on SteelHeads:

U.S. export restrictions require that this license is installed on each SteelHead that has SSL optimization enabled. You can acquire an enhanced cryptography license key by filling out the online form available at http://sslcert.riverbed.com.

The proxy certificate is the certificate you configure on the server-side SteelHead for the server. Do not confuse this certificate with the certificate used for the secure inner channel or secure peering between the two SteelHeads and, also, the server certificate that is installed on the Web and application server.

The proxy certificate can be self-signed, signed by a well-known CA, or signed by your organization's own CA. It can be the same as, or different from, the certificate used by the actual server. The correct type of certificate depends on your deployment.

You can use a single wild card certificate and its private key as the proxy certificate for multiple servers.

For example, you might have three distinct servers using different certificates: sales.riverbed.com, internal.riverbed.com, and marketing.riverbed.com. You can add each of the three server certificates (as the proxy certificates) and their corresponding private keys, or you can add a single wild card certificate (*.riverbed.com) with its private key.

RiOS v6.0 or later simplifies the SSL configuration process because the server-side SteelHead does not need to have a proxy certificate for each server individually. Prior to v6.0, you had to provide an IP address, port, and certificate to enable SSL optimization for a server. This method is impractical in cases where multiple servers shared the same server certificate because each server had to have a corresponding entry on the server-side SteelHead.

In RiOS v6.0 or later, you simply add unique proxy certificates to a certificate pool on the server-side SteelHead. When a client initiates an SSL connection with a server, the SteelHead matches the common name of the certificate on the server with one in its proxy certificate pool. If it finds a match, it adds the server to the list of optimizable servers, and all subsequent connections to that server are optimized with the same proxy certificate.

If it does not find a match, it adds the server name to the list of bypassed servers and all subsequent connections to that server are not optimized. The optimizable and bypassed server lists appear on the server-side SteelHead SSL Main Settings page of the Management Console.

If your proxy certificate and private key are in a format other than PEM, PCKS12, or DER, you must convert the certificate and key before you import them. The file extension does not necessarily dictate the encoding, as many common extensions such as .crt, .cer or .key can be either PEM or DER encoded.

To convert a certificate and private key, Riverbed recommends using an open source toolkit such as OpenSSL. For details, go to http://www.openssl.org/.

For information about converting a Base64 encoded PCKS12 certificate to PEM, see the Riverbed Knowledge Base article Converting a PCKS12 Certificate/Key to PEM at https://supportkb.riverbed.com/support/index?page=content&id=S13301.

You can use intermediary certificates instead of signing all certificates with a root level certificate. In releases earlier than RiOS v5.5, you needed to put all of the intermediate certificates on the server-side SteelHead and keep them up-to-date. With RiOS v5.5 or later, you can configure the server-side SteelHead to automatically pull down intermediate certificates from the back-end server.

Use the following command on the server-side SteelHead to enable certificate chain discovery:

Alternatively you can use the Management Console to enable certificate chain discovery. Choose Optimization > SSL: Advanced Settings and select Enable SSL Server Certificate Chain Discovery. By default, this option is disabled.

Before the server-side SteelHead can establish an SSL connection to the server, it needs to verify the authenticity of the server certificate. This verification is based upon the model of trust relationships established within a public key infrastructure.

In this model, the issuer of the certificate is a third party that is trusted by both the subject (owner) of the certificate and the party (client) relying on the certificate. A certificate authority (CA) is an entity that issues a certificate. A client establishes a trust relationship to the CA first, and subsequently, uses the certificate of the CA to verify the authenticity of a server certificate. A SteelHead establishing an SSL connection acts as a client.

A SteelHead includes a list of commonly used public CA certificates preinstalled. When the certificate of your server is signed by a private CA, you must install that private CA certificate in the server-side SteelHead. This certificate establishes the trust relationship to the private CA and, consequently, the server certificates that this private CA issues.

Each SteelHead participating in SSL optimization requires a peer certificate. The peer certificates allow the client-side and server-side SteelHeads to establish a secure inner channel. You can distribute these certificates several different ways: manual cut-and-paste; using the white, gray, and black peering lists; or through the SCC.

The peer certificates between the SteelHeads can be, and in most cases are, self-signed certificates. The session keys derived between the SteelHeads are used for encrypting data within the secure inner channel. The encrypted data ensures that the SSL session is secure end to end. For details, see Overview of SSL.

This section describes a simple deployment to help you set up, test, and understand basic SSL optimization functionality. This simple deployment chooses simplicity over security, and installs a self-signed proxy certificate on the server-side SteelHead. You can test this deployment against an operational Web server that uses SSL.

To complete this deployment, you need two SteelHeads, a WAN simulator, a LAN connection between the client and client-side SteelHead, and another LAN connection between the server and the server-side SteelHead. This example uses a self-signed certificate; however, the configuration steps remain the same for a CA-signed certificate.

This deployment assumes that your Web server is configured for SSL connections and is running, and that the client-side and the server-side SteelHeads can optimize non-SSL TCP traffic.

For information about troubleshooting and verification, see Troubleshooting and Verification.

The SteelHeads are capable of automatically detecting and configuring secure peering (SSL) between themselves if they are both using self-signed secure peering certificates. If SSL optimization is correctly configured on both the client-side and server-side SteelHeads, the self-signed secure peering certificate of the client-side SteelHead automatically populates into the server-side SteelHead self-signed peer gray list (Figure 11‑9) and vice versa after an SSL connection is attempted across the SteelHeads. Use the drop-down menu to move the peer SteelHead into either self-signed peer white list or self-signed peer black list.

For more information, see Secure Peering Using the Self-Signed Peer White, Gray, and Black Lists.

The client uses the proxy certificate to secure the SSL session instead of the server certificate in a SteelHead optimized SSL connection. This usage is because of the way the SteelHead terminates an optimized SSL connection. For more information, see How SteelHeads Terminate an Optimized SSL Connection.

The following table shows the four options available for generating the proxy certificate and its private key. The proxy certificate and its private key are installed in the server-side SteelHead. To optimize an SSL session, a proxy certificate for the server is required.

In an optimized SSL session, the client receives the proxy certificate instead of the server certificate. The proxy certificate might or might not be the same as the server certificate. This scenario is the same for its private key. Nonetheless, the choice of proxy certificate is transparent to the client as the server common name in both certificates is the same, and the connection is secure end-to-end.

For more information, see How SteelHeads Terminate an Optimized SSL Connection and Proxy Certificate and Private Key.

You can use the following methods to configure the peer certificates used for secure peering (SSL) between the client-side and server-side SteelHeads:

You can use peering lists to configure peer certificates on SteelHeads running RiOS v5.0 or later. When SSL optimization is enabled, and an optimizable SSL connection is attempted across the SteelHeads, the remote peer is detected and its peering certificate is automatically populated into the self-signed peer gray list. The connection remains unoptimized because the remote peer is listed in the self-signed peer gray list.

You can examine the peer certificate for authenticity and move any peer from the gray list to either the white list or the black list. If you trust the remote peer, move it into the self-signed peer white list to begin optimizing the SSL connection. If you do not trust the remote peer, move it into the self-signed peer black list to prevent the SSL connection from being optimized.

Proxy Certificate	Private Key	Description
Real server certificate	Real private key	You can reuse the real server certificate and private key pair as the proxy certificate and private key pair. This option is ideal but is not always be available. For example, you can connect to a cloud-hosted application over SSL that uses a public certificate. The real server certificate and its private key are not available to you because you do not belong to the organization that owns the application.
New CA-signed proxy certificate	Real private key	You may reuse the real private key but create a new proxy certificate that is signed by a different CA. The real private key is required in situations where there is a security dependency from the client application, for example, when using client certificates for authentication. Choose this option if you want to administer all of your SteelHead proxy certificates (and secure peering certificates) from a different CA, for example, the SCC CA. You can also have some other requirements that cannot be fulfilled by the real CA, for example, the security requirements preclude server impersonation, the subject alternative names are a problem, you desire a longer validity period than the original certificate, or you want to use a wild card common name that is broader than the original. When using a CA-signed certificate, the CA certificate must be installed in the trusted root certification authorities store of the client machine.
New CA-signed proxy certificate	New private key	You can generate a new CA-signed proxy certificate and private key pair. This option can be an administratively quick way to obtain a new proxy certificate and private key pair for SteelHead SSL optimization. If your SteelHeads are managed with SCC v8.6 or higher, you can use the SCC CA to generate the new proxy certificate and private key pair.
New self-signed proxy certificate	New private key	You can generate a new self-signed proxy certificate and private key pair. A SteelHead is capable of generating a new self-signed certificate and private key pair for its proxy and peering certificates. This is the fastest option available and can be used temporarily to fulfill the requirement. However, for security purposes, some browsers and applications do not accept self-signed certificates. You cannot establish the SSL connection in this case.

Figure 11‑10 shows how you can move the peer certificate into either the white or black list with the drop-down menu.

To verify that the SSL connection is successfully optimized after you have configured secure peering, view the connection in Reports > Networking: Current Connections. For information about verifying SSL connections, see Troubleshooting and Verification.

If you use CA-signed peer certificates, you can configure the SteelHead to trust the CA certificate instead of the peer certificate. The SteelHead implicitly trusts all certificates that the trusted CA issues. Alternatively, you can manually add the peer certificate into the peering trust list.

If you have an intermediary CA, you must add them with the root CA. In secure peering, both the client-side and server-side SteelHead functions as a SSL client and server at the same time. For more details, go to https://supportkb.riverbed.com/support/index?page=content&id=S14925.

Riverbed recommends that you configure a medium-to-large SteelHead deployment for SSL optimization with the help of an SCC. The SCC can simplify the configuration of SSL optimization and secure peering, and increase the operational efficiency of a SteelHead deployment through central management thereby enabling the deployment size to easily scale.

The configuration effort required to manage the secure peering certificates and trusts in a SteelHead deployment increases proportionally with the number of SteelHeads deployed. The increase is due to the following reasons:

A secure inner channel must be set up between the client-side and server-side SteelHead in a deployment where SSL traffic or any other secure protocol traffic, such as signed-SMB and encrypted-MAPI, are optimized. Secure protocol traffic, including SSL traffic, are passed through the secure inner channel to maintain end-to-end data security. SCC v8.6 and later incorporates a certificate authority that can be used to centrally issue, distribute, and manage the secure peering certificates and peering trusts, in addition to the proxy certificates for SSL optimization. Using and trusting only CA-signed certificates increases the security model of an SSL deployment.

For information about using the SCC CA to manage the secure peering certificates and trust, see the SteelCentral Controller for SteelHead Deployment Guide. For information about adding a certificate authority to the secure peering trust configuration, see Secure Peering with CA-Signed Certificates.

In a high-security environment, you might want only known and trusted SteelHeads to peer for optimized traffic flows. Prior to RiOS v6.0, you could control peering only by modifying the peering tables, which was limiting because a secure model of peering trust could not be established between the SteelHeads. Modifying the peering tables creates situations in which SteelHeads can peer and optimize flows that might not be explicitly trusted. Using SSL secure peering, and forcing all traffic flows to flow through the secure inner channel, you can create an environment of explicit trust—only SteelHeads that can trust its peers can peer and optimize traffic flows.

In federated networks, it is common for organizationally separate SteelHeads to be aware of each other. If you use only secure peering, you create an environment of trust between the SteelHeads. If the secure inner channel connection fails, all conversations between the SteelHeads pass through. For more information about setting up secure peering, see Setting Up a Simple SSL Optimization Deployment or SteelHead Secure Peering Scenarios.

Figure 11‑14 shows a client connection to a server. The default behavior of the SteelHead is to optimize this connection. In an environment in which secure peering is used for all optimized traffic, the SteelHeads have to trust each other before a secure inner channel can be established to carry the optimized traffic. Use the following procedure to set up a SteelHead to secure all optimized traffic and only optimize through a secure inner channel.

If you select All from the Traffic Type you can cause up to a 10% performance decline in higher-capacity SteelHeads. Take this performance metric into account when sizing a complete secure SteelHead peering environment.