TECHNICAL BRIEF
Riverbed SSL Proxy Certificate Support
Introduction
This document describes how the Riverbed Steelhead appliance
returns the local installed proxy certificate to client application during
the SSL/TLS handshake process for server authentication.
Information on generating the certificates, peering setup, and
configuring SSL optimization on the Steelhead appliances are not
covered in this document and can be found in the Steelhead
Management Console User’s Guide.
Steelhead SSL Optimization
The Riverbed SSL solution accelerates data transfers that are
encrypted using SSL/TLS. While ensuring end-to-end security, an
important aspect of the solution is that private keys remain in the data
center and are not exposed in the remote branch office location where
it is generally accepted to be less secure.
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 SSL
acceleration, the full SSL handshakes terminate on the server-side
Steelhead appliance; therefore, you will need to install proxy
certificates and private keys on the server-side Steelhead appliance for
the purpose of emulating the origin server.
Figure1: Steelhead SSL optimization with server-side Steelhead terminates the SSL handshake
Steelhead and Proxy Certificates
The proxy certificate is the certificate you configure on the server-
side Steelhead appliance for the SSL server. A proxy certificate can
be one of the following: the original server certificate, a self-signed
certificate, a certificate signed by a public Certificate Authority (CA)
(e.g. VeriSign), or a certificate signed by an enterprise CA.
RiOS simplifies the SSL configuration process because it eliminates
the need to add each server certificate individually. You can add
unique certificates to the server-side Steelhead appliance, or 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
origin servers using different certificates: sales.riverbed.com,
engineering.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
common name (CN) wild card certificate (*.riverbed.com) with its
private key.
Server-side Steelhead Returns Proxy Certificate
to Client
Modern browsers and SSL/TLS applications typically use both
common name (CN) and the entries on the subject alternative name
1
 TECHNICALBRIEF

Riverbed SSL Proxy

Certificate Support

(SAN) extension for a certificate match. Name-based virtual hosting allows different domain hostnames to be hosted by a single server on
the same IP. Without knowing the server hostname during the SSL handshake, the server will present the default certificate to client. If the
hostname is not included in the certificate that the client tries to access, an error will be returned. If server name indication (SNI) extension is
supported, the client hello handshake message will include the requested virtual hostname to which the client is connecting. Because the
server is aware of the hostname, it returns a host-specific certificate.

For Steelhead SSL optimization, once the server-side Steelhead appliance verifies the backend server certificate it receives from the origin
server, the Steelhead appliance matches the CN 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.

The flow chart on the left demonstrates how the Steelhead appliance selects the proxy certificate for the SSL client after it receives the
server certificate:
The Steelhead appliance never uses the SAN entries of its proxy
certificates to compare it to the CN of the server certificate;
however, it does use the CN of its proxy certificates and
compares it against the SAN entries of the server
certificate. Wildcard name is supported so it can be used as part
of CN if it is an option. Let’s walk through an example with the
flow chart. For example, the origin server certificate is signed by
an enterprise CA with CN of www.domainA.com, and it does not
contain any SAN entry. The proxy certificate is signed by the
same CA with a CN of demo.domainA.com and SAN entries of
*.domainA.com. To start the selection algorithm, first, the public
key of demo.domainA.com and the public key of
www.domainA.com do not match, so it continues to check the
server CN (www.domainA.com) which does not match to the
proxy CN (demo.domainA.com). Finally, demo.domainA.com is
not listed in the SAN field of the server certificate so the
Steelhead appliance will return an error and add the server to SSL
bypass list.

With SNI feature introduced in RiOS 8.5 and later, the server-side
Steelhead appliance will perform a secondary check to make sure
the SNI matches the CN or the SAN entries of the selected proxy
certificate. Only after it passes certificate selection algorithm, the
proxy certificate can be presented to the client’s browser.
Once the proxy certificate is selected and presented to the client,
the client will need to verify the proxy certificate with CA that is
stored in the local certificate manager. Since the client will use the
SAN field for hostname or domain verification, it’s important for
the proxy certificate to contain the SANs of the original certificate.
If the hostname does not match to either CN or SAN in the proxy
certificate, the client application will return a warning message. If
the proxy certificate passes the verification, the client continues
the SSL handshake process to create the secret key to server-
side Steelhead appliance.

About Riverbed
Riverbed delivers application performance for the globally connected enterprise. With Riverbed, enterprises can successfully and intelligently implement
strategic initiatives such as virtualization, consolidation, cloud computing, and disaster recovery without fear of compromising performance. By giving
enterprises the platform they need to understand, optimize and consolidate their IT, Riverbed helps enterprises to build a fast, fluid and dynamic IT
architecture that aligns with the business needs of the organization. Additional information about Riverbed (NASDAQ: RVBD) is available at
www.riverbed.com.

©2014 Riverbed Technology. All rights reserved.

Riverbed and any Riverbed product or service name or logo used herein are trademarks of Riverbed Technology. All other trademarks used herein belong to their respective owners. The trademarks and logos displayed 2
herein may not be used without the prior written consent of Riverbed Technology or their respective owners.