Configuring SSL server certificates and certificate authorities
This section provides an overview of SSL support and describes how to configure SSL server certificates and certificate authorities.
SSL is a cryptographic protocol that provides secure communications between two parties over the internet. Typically, in a web-based application, it is the client that authenticates the server. To identify itself, an SSL certificate is installed on a web server and the client checks the credentials of the certificate to make sure it is valid and signed by a trusted third party. Trusted third parties that sign SSL certificates are called certificate authorities (CA).
How does SSL work?
With Riverbed SSL, SteelHeads are configured to have a trust relationship, so they can exchange information securely over an SSL connection. SSL clients and servers communicate with each other exactly as they do without SteelHeads; no changes are required for the client and server application, nor are they required for the configuration of proxies. RiOS splits up the SSL handshake, the sequence of message exchanges at the start of an SSL connection.
In an ordinary SSL handshake, the client and server first establish identity using public-key cryptography, and then negotiate a symmetric session key to be used for data transfer. With Riverbed TLS acceleration the client and server side SteelHead establish independent sessions to the client and server respectively.
Riverbed SSL
Version 9.14.1 SteelHeads and later interoperate with peers where TLS optimization is enabled. TLS optimization was first introduced in version 9.10.1 SteelHeads and Client Accelerator 6.3.1. Connections from peers running older versions automatically are passed through.
TLS optimization supports features such as SSL Simplification and TLS v1.3 protocol. SSL Simplification refers to deployments where the Client Accelerator automatically provides certificates and brokers access to client certificates for client-authenticated connections.
The SteelHead also contains a secure vault that stores all SSL server settings, other certificates (that is, the CA, peering trusts, and peering certificates), and the peering private key. The secure vault protects your SSL private keys and certificates when the SteelHead isn’t powered on. You set a password for the secure vault that is used to unlock it when the SteelHead is powered on. After rebooting the SteelHead, SSL traffic isn’t optimized until the secure vault is unlocked with the correct password. See
Unlocking the secure vault.
Prerequisite tasks
Complete these prerequisite tasks before you begin SSL configuration:
1. Connect to the Management Console using HTTPS to protect your SSL private keys and certificates.
The SSL License (Enhanced Cryptographic License Key) also activates RiOS data store encryption and creates secure channels while optimizing encrypted MAPI and SMB-signed traffic (even if the SteelHeads aren’t configured for optimizing SSL traffic).
3. Back up your private keys and the CA-signed certificates before you begin the SSL configuration process.
Basic steps
This section provides an overview of the basic steps to configure SSL, followed by detailed procedures.
Task | Reference |
1. Enable TLS support on the server-side and client-side SteelHeads. | |
2. Set the SSL secure vault password on the client-side and server-side SteelHead. | |
3. On the server-side SteelHead, configure a proxy certificate and private key for the SSL back-end server. This step enables the client-side SteelHead to act as a proxy for the back-end server, which is necessary to intercept the SSL connection and to optimize it. | |
4. Create an in-path rule for the client-side SteelHead. In-path configurations—Create a client-side in-path rule with the Preoptimization Policy = SSL. If you want to enable the HTTP latency optimization module for connections to this server, you add a corresponding in-path rule with Latency Optimization Policy = HTTP. Out-of-path configurations—On the client-side SteelHead, add a new in-path rule to identify which connections are to be intercepted and applied to SSL optimization. Use these property values: – Type—Fixed target – Destination Subnet/Port—We recommend you specify the exact SSL server IP address (for example, 10.11.41.14/32) and the default SSL port 443. – VLAN Tag—All – Preoptimization Policy—SSL – Data Reduction Policy—Normal – Latency Optimization Policy—HTTP Note: Latency optimization isn’t always HTTP, especially for applications that use the SSL protocol but aren’t HTTP based. In such cases, specify None for the latency optimization. – Neural Framing Mode—Always | |
5. Configure mutual peering trusts so the server-side SteelHead trusts the client-side SteelHead and vice versa. Use one of these approaches: Use the secure inner channel and peering lists: – To automatically discover SteelHeads using self-signed certificates, open your secure application to send some traffic through the SteelHeads. The connection is passed through to the server without optimization, but the SteelHeads will automatically discover the peers and place them in the self-signed peer graylist. – Manually move the peers from the graylist to the trusted whitelist by simply marking them as trusted. The connections aren’t optimized until after you move the peers to the whitelist. – Reopen your secure application. —or— Add CA-signed peer certificates: – Add the PEM certificate of the designated CA as a new trusted entity to the peering trust list for each SteelHead. – For production networks with multiple SteelHeads, use the SCC or the bulk import and export feature to simplify configuring trusted peer relationships. For details, see the SteelCentral Controller for SteelHead User Guide or
About bulk imports and exports. Your organization can choose to replace all of the default self-signed identity certificates and keys on their SteelHeads with those certificates signed by another CA (either internal to your organization or an external well-known CA). In such cases, every SteelHead must simply have the certificate of the designated CA (that signed all those SteelHead identity certificates) added as a new trusted entity. | |
6. If your organization uses internal CAs to sign their SSL server certificates, you must import each of the certificates (in the chain) on to the server-side SteelHead. You must perform this step if you use internal CAs because the SteelHead default list of well-known CAs (trusted by our server-side SteelHead) doesn’t include your internal CA certificate. To identify the certificate of your internal CA (in some cases, the chain of certificate authorities) go to your web browser repository of trusted-root or intermediate CAs: for example, Internet Explorer > Tools > Internet Options > Certificates. | |
7. On the client-side and server-side SteelHead, restart the optimization service. | |
Verifying SSL and secure inner channel optimization
Use these tools to verify that you have configured SSL support correctly:
• SSL Optimization—After completing the SSL configuration on both SteelHeads and restarting the optimization service, access the secure server from the web browser. These events take place in a successful optimization:
– If you specified a self-signed proxy certificate for the server on the server-side SteelHead, a pop-up window appears on the web browser. View the certificate details to ensure that it’s the same as the certificate on the server-side SteelHead.
– In the Management Console, the Current Connections report lists the new connection as optimized without a red protocol error.
– In the Management Console, the Traffic Summary report displays encrypted traffic (typically, HTTPS).
– Verify that the back-end server IP appears in the SSL Discovered Server Table (Optimizable) in the SSL Main Settings page.
• Monitoring SSL Connections—Use these tools to verify SSL optimization and to monitor SSL progress:
– On the client web browser, click the Lock icon to obtain certificate details. The certificate must match the proxy certificate installed on server-side SteelHead.
– In the Current Connections report, verify the destination IP address, port 443, the Connection Count as Established (three yellow arrows on the left side of the table), SDR Enabled (three cascading yellow squares on the right side of the table), and that there’s no Protocol Error (a red triangle on the right side of the table).
– In the SSL Statistics report looks for connection requests (established and failed connections), connection establishment rate, and concurrent connections.
• Monitoring Secure Inner Channel Connections—Use these tools to verify that secure inner channels are in use for the selected application traffic types:
– In the Current Connections report, look for the Lock icon and three yellow arrows, which indicate the connection is encrypted and optimized. If the Lock icon is not visible or is dimmed, click the magnifying glass to view a failure reason that explains why the SteelHead is not using the secure inner channel to encrypt the connection. If there’s a red protocol error, click the magnifying glass to view the reason for the error.
– Search the client-side and server-side SteelHead logs for ERR and WARN.
– Check that both SteelHeads appear in the white peering trust list on the client-side and server-side SteelHeads, indicating that they trust each other.
TLS optimization requires that Server Name Indication (SNI) is used in the TLS handshake. This is originated by the client and has been a standard for over a decadeContact Support if you have customized or non-standard applications.