Setting advanced SSL options

Control	Description
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. This option never replaces the server certificate. It updates the chain containing the intermediate certificates and the root certificate in the client context.
SteelHead Mobile Security Mode	On the server-side SteelHead, select one of these security modes: • High Security Mode—Enforces the advanced SSL protocol on the Client Accelerators for increased security. • Mixed Security Mode—Allows Client Accelerator Controller clients to run in any SSL mode. This mode is required to optimize with mobile clients running on VMware Fusion. This option doesn’t affect SteelHead-to-SteelHead operation.
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. • Timeout—Specify the amount of time the client can reuse a session with an SSL server after the initial connection ends. The range is from 6 minutes to 24 hours. The default value is 10 hours. Enabling this option requires an optimization service restart.
Client Certificate Support	Enables support for client certificates during the SSL authentication. You can choose from these three modes: On, Off, and Peering. • Off—By default, client certificate support is off and the SSL handshake relies only on a server certificate. • On—This mode relies on passive key derivation. The On setting 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. Setting the client authentication to On 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. If the data center has a mixed environment with a few SSL servers that authenticate clients along with those that don’t authenticate clients, we recommend enabling client authentication. Requirements • Enable client certificate support on the server-side SteelHead. • The server-side SteelHead must have access to the exact private key used by the SSL server. • The SSL server must be configured to ask for client certificates. • The SteelHead must have a compatible cipher chosen by the server. • SSL sessions that reuse previous secrets that are unknown to the SteelHead can’t be decrypted. • Client-side certificates with renegotiation handshakes aren’t supported. • Client certificate supports the RSA key exchange only. It doesn’t support the Diffie-Hellman key exchange.
	Basic steps to enable client authentication 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 On for 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. Verification 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. • Peering—In peering mode, the SteelHead needs a proxy certificate for the connection, but it does not need the origin server’s private key. This mode lets the SteelHead respond to client authentication requests by using its peering certificate. This is a more traditional implementation where the SteelHead acts as a trusted “man-in-the-middle.” When a client certificate request arrives from the server: 1. The server-side SteelHead replies to the server’s client certificate request with its own peering certificate. 2. The client-side SteelHead requests a client certificate in response to the client hello. 3. The client-side SteelHead authenticates the client certificate using the existing trusted CA repository. This mode supports the Ephemeral Diffie-Hellman key exchange.
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: • create an in-path rule on the client-side SteelHead to identify the proxy server IP address and port number. Select the SSL preoptimization policy for the rule. • enable SSL optimization on both the client-side and server-side SteelHeads. • ensure both the client-side and server-side SteelHeads are running RiOS 7.0 or later. • restart the optimization service on both SteelHeads. 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: • Both the client-side and server-side SteelHeads must be running RiOS 7.0 or later. • The SSL client must be the same as the TCP client. • SSL messages can’t be wrapped with any other non-SSL or non-TCP protocol headers or footers. • SSL optimization must be enabled on both the client-side and server-side SteelHeads.
Enable SNI support for Virtual Hosting	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 enables the following SNI support on the server-side SteelHead, regardless of whether this SNI control is enabled: • Adds the SNI extension from the client Hello to the server-side SteelHead client Hello. • Uses the SNI extension to match and select the proxy certificate to return to the client.
OCSP Stapling Support	Enables Online Certificate Status Protocol (OCSP) stapling. OCSP is an alternative approach to obtain certificate status from the OCSP servers instead of the origin server’s Public Key Infrastructure (PKI). You only need to enable this feature on the server-side SteelHead. Specify one of these stapling levels: • Off—Disables OCSP if it has been enabled. By default, OCSP is disabled. • Strict—If the origin server does not support OCSP, the connection is bypassed (dropped, not optimizable). • Strict AIA—If the certificate included an Authority Information Access (AIA) field but the origin server failed to send an OCSP response, the connection is bypassed. If the certificate did not include an AIA field and the origin server failed to send an OCSP response, the connection is not dropped because the server-side SteelHead does not expect an OCSP response. • Loose—If the origin server does not support OCSP, the connection is not dropped.
Enable TLS Blade	Enables TLS optimization. This feature provides zero-touch certificate management for clients that have a Client Accelerator installed. This feature requires RiOS 9.12 or later on the client-side and server-side SteelHeads and Client Accelerator 6.2.2 or later on each client endpoint. For details on configuring TLS optimization in the Client Accelerator, see the Client Accelerator User Guide. For details on SSL simplification on the SteelHead, see SSL simplification. When you enable TLS optimization, the old SSL blade and the new TLS blade are active in the SteelHead and Client Accelerator. TLS optimization is activated only when it is enabled on both SteelHead peers and the Client Accelerator (or the Client Accelerator and the SteelHead). Otherwise, the old SSL blade will continue to be used. You must have Client Accelerator 6.2.2 installed on a device to use this feature.