Enable SSL Server Certificate Chain Discovery

Synchronizes the chain certificate configuration on the server-side SteelHead with the chain certificate configuration on the back-end server. The synchronization occurs after a handshake fails between the client-side and server-side SteelHead. By default, this option is disabled.

Enable this option when you replace an existing chain certificate on the back-end server with a new chain to ensure that the certificate chain remains in sync on both the server-side SteelHead and the back-end server.

SteelHead Mobile Security Mode

On the server-side SteelHead, select one of these security modes:

Enable Distributed SSL Termination

Enables reuse of the original session on a client-side SteelHead when the client reconnects to an SSL server. Reusing the session provides two benefits: it lessens the CPU load because it eliminates expensive asymmetric key operations and it shortens the key negotiation process by avoiding WAN roundtrips to the server. By default, this option is enabled. Both the client-side and server-side SteelHeads must be configured to optimize SSL traffic.

Enabling this option requires an optimization service restart.

Enable Client Certificate Support

Enables acceleration of SSL traffic to those SSL servers that authenticate SSL clients. The SSL server verifies the SSL client certificate. In the client authentication SSL handshake, each client has a unique client certificate and the SSL server, in most cases, maintains the state that is specific to each client when answering the client's requests. The SSL server must receive exactly the same certificate that is originally issued for a client on all the connections between the client and the server. Typically the client's unique certificate and private key are stored on a smart card, such as a Common Access Card (CAC), or on a similar location that is inaccessible to other devices on the network.

By default, client authentication is disabled.

Enabling the client authentication feature allows SteelHeads to compute the encryption key while the SSL server continues to authenticate the original SSL client exactly as it would without the SteelHeads. The server-side SteelHead observes the SSL handshake messages as they go back and forth. With access to the SSL server's private key, the SteelHead computes the session key exactly as the SSL server does. The SSL server continues to perform the actual verification of the client, so any dependencies on the uniqueness of the client certificate for correct operation of the application are met. Because the SteelHead doesn’t modify any of the certificates (or the handshake messages) exchanged between the client and the server, there’s no change to their trust model. The client and server continue to trust the same set of certificate authorities as they did without the SteelHeads accelerating their traffic.

 

The basic steps to enable client authentication are:

1. Perform the basic steps to enable SSL optimization (described in Configuring SSL Server Certificates and Certificate Authorities).

2. On the server-side SteelHead, choose Optimization > SSL: Advanced Settings, select Enable Client Certificate Support, and click Apply.

3. Choose Optimization > SSL: SSL Main Settings, import the private key and certificate used by the SSL server to the server-side SteelHead, and click Save to Disk to save the configuration. You don’t need to restart the optimization service.

To verify client authentication, on the server-side SteelHead, check the Discovered Server (Optimizable) table in the Optimization > SSL: SSL Main Settings page. Optimizable servers that are using client authentication appear as optimizable. For servers that aren’t using client authentication, the server appears in the Discovered Server (bypassed, not optimizable) table with the reason “No proxy certificate configured for the server.”

Enable SSL Proxy Support

Enable this control on both the client-side and server-side SteelHeads when clients are communicating with SSL to a server through one or more proxies. Proxy support allows the SteelHead to optimize traffic to a proxy server.

SSL traffic communication with a proxy initiates with an HTTP CONNECT message. The SteelHead recognizes the HTTP CONNECT message in the connection, extracts the hostname, and then optimizes the SSL connection that follows into the proxy state machine (expecting an SSL handshake following the CONNECT message).

In addition to enabling this feature on both SteelHeads, you must:

By default, SSL proxy support is disabled.

When the SteelHead connects, the proxy servers appear in the SSL Main Settings page on the server-side SteelHead in the Discovered SSL Server (Optimizable) list. The same IP address appears on multiple lines, followed by the word “proxy.” The hostname of the back-end server appears in the Server Common Name field. All subsequent connections to the proxy servers are optimized.

When an error occurs, the proxy servers appear in the SSL Main Settings page on the server-side SteelHead in the Discovered Servers (bypassed, not optimized) list. The same IP address appears on multiple lines, followed by the word “proxy.” The hostname of the back-end server appears in the Server Common Name field. All subsequent connections to the servers aren’t optimized.

If you disable proxy support, you must delete the corresponding in-path rule and restart the optimization service.

Enable Midsession SSL

Enable this control on both the client-side and server-side SteelHeads when there’s a delayed start to the Transport Layer Security (TLS) handshake because clients are transitioning into SSL after the initial handshake occurs. This feature optimizes connections that transition into SSL.

Client examples include SMTP/POP/IMAP-over-TLS and Microsoft .NET Windows Communication Foundation (WCF)-based TLS applications. This feature also enables SSL communication with protocols like Exchange-Hub to Exchange-Hub replications (for example, the SMTP-over-TLS protocol).

For details on SMTP over TLS Optimization, see the SteelHead Deployment Guide - Protocols.

The SteelHead looks for an SSL handshake for the life of the connection, and then optimizes the SSL connection that follows (except for an SSL handshake following the HTTP CONNECT message, in which case the SSL proxy support feature needs to be enabled).

After enabling this feature on both SteelHeads you must restart the optimization service.

When the SteelHead connects, the servers appear in the SSL Main Settings page on the server-side SteelHead in the Discovered SSL Server (Optimizable) list. All subsequent connections to the servers are optimized.

TLS 1.2 support is enabled by default in RiOS 9.2. To disable TLS 1.2, enter the no protocol ssl backend client-tls-1.2 CLI command.

Requirements:

Enable SNI

Enable this control on the server-side SteelHead while using name-based virtual hosts with SSL. Server name indication (SNI) is a transport layer security extension to the SSL protocol. With SNI, the first SSL client hello handshake message sent to the HTTPS server includes the requested virtual hostname to which the client is connecting. Because the server is aware of the hostname, it returns a host-specific security certificate.

Without SNI, an HTTPS server returns a default certificate that satisfies hostnames for all virtual hosts. The SSL connection setup uses the default virtual host configuration for the address where the connection was received. Browser messages warn that certificates have the wrong hostname.

With SNI enabled, RiOS provides the hostname. Knowing the hostname enables the server to determine the correct named virtual host for the request and set up the connection accordingly from the start.

The browser validates the certificate names against the requested URL, and the server-side SteelHead verifies that the selected proxy certificate is compatible with the client hostname. This verification ensures that the browser doesn’t reject the proxy certificate for the server-side SteelHead.

If SNI provides a hostname that doesn’t exactly match the common name or any of the subject alternate names for the certificate on the server-side SteelHead, the system determines that a valid certificate is not present and bypasses that hostname.

No configuration is necessary on the client-side SteelHead.

The client browser must also support SNI.

By default, RiOS 9.2 enables the following SNI support on the server-side SteelHead, regardless of whether this SNI control is enabled: