Configuring secure peers
You configure secure peers under Optimization > SSL: Secure Peering (SSL). Secure, encrypted peering extends beyond traditional SSL traffic encryption. In addition to SSL-based traffic like HTTPS that always needs a secure connection between the client-side appliance and the server-side SteelHead, you can also secure other types of traffic such as:
• MAPI-encrypted, SMB1, and SMB2-signed traffic.
• Citrix traffic.
• all other traffic that inherently does not require a secure connection.
SSL secure peering and secure transport traffic can coexist.
Secure inner channels
Each appliance is manufactured with its own self-signed certificate and private key, which uniquely identify that appliance. The secure inner channel setup process begins with the peer appliances authenticating each other by exchanging certificates and negotiating a separate encryption key for each intercepted connection. Next, the appliances create corresponding inner connections for all outer connections between the client and the client-side appliance and between the server and the server-side SteelHead.
Peers are detected the first time a client-side appliance attempts to connect to the server. The optimization service bypasses this initial connection and does not perform data reduction, but rather uses it to detect peers and populate the peer entry tables. On both appliances, an entry appears in a peering list with the certificate of the other peer and identifying information such as IP address and hostname. You can then accept or decline the trust relationship with each appliance requesting a secure inner channel.
After the appliances trust each other, they send encrypted data between themselves over secure inner connections matching the outer connections of the selected traffic types. The trust relationship between the appliances is bidirectional; the client-side appliance trusts the server-side SteelHead, and vice versa.
We recommend using the secure inner channel in place of IPsec encryption to secure traffic.
Secure peers
You secure traffic between client-side appliances and server-side SteelHeads.
You rarely need to replace a self-signed certificate on a SteelHead; however, if you do, add the CA’s certificate to the peering trust section so each SteelHead can verify the peer certificate for its peers.
If you are securing encrypted MAPI traffic or Citrix traffic, enable one of these settings on both the server-side and client-side appliances:
• Choose Optimization > Protocols: MAPI and select Enable Encrypted Optimization.
—or—
• Choose Optimization > Protocols: Citrix and select Enable SecureICA Encryption. Both appliances must be running RiOS 7.0 or later.
If you are securing SMB-signed traffic, choose Optimization > Protocols: CIFS and select Enable SMB Signing on the server-side SteelHead.
We recommend using NTP time synchronization or manually synchronizing the clocks on both the server-side SteelHead and client-side appliances. It is critical that the peer appliance time is the same for the trust relationship to work.
On both the server-side SteelHeads and client-side appliances, choose Optimization > SSL: Secure Peering (SSL) to display the Secure Peering (SSL) page.
Under SSL Secure Peering Settings, these configuration options are available:
Traffic Type
Specifies one of these traffic types from the drop-down list:
• SSL Only—The peer client-side SteelHead and the server-side SteelHead authenticate each other and then encrypt and optimize all SSL traffic: for example, HTTPS traffic on port 443. This is the default setting.
• SSL and Secure Protocols—The peer client-side SteelHead and the server-side SteelHead authenticate each other and then encrypt and optimize all traffic traveling over these secure protocols: Citrix, SSL, SMB-signed, and encrypted MAPI.
MAPI encryption or Secure ICA encryption must be enabled on both the client-side and server-side SteelHeads when securing encrypted MAPI traffic, or encrypted Citrix ICA traffic (RiOS 7.0 and later).
Enabling this option requires an optimization service restart.
• All—The peer client-side SteelHead and the server-side SteelHead authenticate each other and then encrypt and optimize all traffic. Only the optimized traffic is secure; pass-through traffic is not. Enabling this option requires an optimization service restart.
Selecting All can cause up to a 10 percent performance decline in higher-capacity SteelHeads. Take this performance metric into account when sizing a complete secure SteelHead peering environment.
Fallback to No Encryption
Specifies that the SteelHead optimizes but doesn’t encrypt the connection when it’s unable to negotiate a secure, encrypted inner channel connection with the peer. This is the default setting. Enabling this option requires an optimization service restart.
We strongly recommend enabling this setting on both the client-side and the server-side SteelHeads, especially in mixed deployments where one SteelHead is running RiOS 7.0 or later and the other SteelHead is running an earlier RiOS version.
This option applies only to non-SSL traffic and is unavailable when you select SSL Only as the traffic type.
Clear the check box to pass through connections that don’t have a secure encrypted inner channel connection with the peer. Use caution when disabling this setting, as doing so specifies that you strictly don’t want traffic optimized between nonsecure SteelHeads. Consequently, when this setting is disabled connections might be dropped. For example, consider a configuration with a client-side SteelHead running RiOS 5.5 and a server-side SteelHead running RiOS 6.0. When this setting is disabled on the server-side SteelHead and All is selected as the traffic type, it will not optimize the connection when a secure channel is unavailable, and might drop it.
If you have changed an encryption setting, you need to restart the optimization service after you apply and save your changes.
The SteelHead supports RSA private keys for peers and SSL servers.
Configuring peer trust
The first time a client-side appliance attempts to connect to the server, the optimization service detects peers and populates the peer entry tables. On both appliances, an entry appears in a peering list with the information and certificate of the other peer. A peer list provides you with the option of accepting or declining the trust relationship with each appliance requesting a secure inner channel. The self-signed peer lists are designated by these color categories:
• White lists all trusted appliances. When you select Trust for a peer in a black or gray list, the public key of the peer is copied into the white list of the local trusted host. The list includes the peer expiration date, IP address, and hostname.
• Black lists all untrusted appliances. When you select Do Not Trust for a peer in a white or gray list, the public key of the peer is copied into the black list of the local untrusted host. The list includes the peer expiration date, IP address, and hostname.
• Gray lists all appliances of unknown status. This list serves as a temporary holding place for all discovered peers that are attempting to establish a secure inner channel. The list includes the peer expiration date, IP address, and hostname. You can select one of these actions to change the status of the peer and move it to the white or black lists: Trust, Do Not Trust, or Remove.
When a self-signed peer has already been added to a peering trust list manually, the SSL server recognizes it upon the first connection from that peer and automatically places it in the white list (without action by the administrator). The certificate that was previously copied and pasted (or imported) into the trusted list is not removed.
The Optimization > SSL: Secure Peering (SSL) page also provides you with these options for configuring peer certificates and Mobile Controller trust:
Peering Trust
Adds and views these types of entities:
• Certificates of trusted peers.
• Certificates of trusted Certificate Authorities (CAs) that may sign certificates for peers.
SCEP Peering Trust
Adds and views trusted Simple Certificate Enrollment Protocol (SCEP) entities.
This list is a subset of the Peering Trust list, and it is used to tag certificates that can be used by SCEP. The SCEP Peering Trust must contain these types of entities:
• SCEP CA certificates
• The CA that was used to sign the Web Certificate for SCEP over HTTPS
Mobile Trust
Adds and views trusted SteelCentral Controller for SteelHead Mobile entities that may sign certificates for SteelHead Mobiles.
Configuring SSL peers
You configure SSL peers under Optimization > SSL: Secure Peering (SSL).
These appliance identity certificate details appears:
Issued To/Issued By
Common Name specifies the common name of the certificate authority.
Organization specifies the organization name (for example, the company).
Locality specifies the city.
State specifies the state.
Country specifies the country.
Serial Number specifies the serial number (Issued To, only).
Signature Algorithm
Specifies the signature secure hash algorithm (SHA) in use by certification authorities to sign certificates and the certificates revocation list (CRL).
Validity
Issued On specifies the date the certificate was issued.
Expires On specifies the date the certificate expires.
Fingerprint specifies the SSL fingerprint.
Key
Type specifies the key type.
Size specifies the size in bytes.
Replacing an existing certificate
Under Certificate, select the Replace tab. These configuration options are available:
Import Certificate and Private Key
Imports the certificate and key. The page displays controls for browsing to and uploading the certificate and key files. Or, you can use the text box to copy and paste a PEM file. The private key is required regardless of whether you are adding or updating the certificate.
Certificate
Upload browses to the local file in PKCS-12, PEM, or DER formats.
Paste it here (PEM) copies and then pastes the contents of a PEM file.
Private Key
Specifies the private key origin:
• The Private Key is in a separate file (see below)—You can either upload it or copy and paste it.
• This file includes the Certificate and Private Key.
• The Private Key for this Certificate was created with a CSR generated on this appliance.
Separate Private Key
Upload (PEM or DER formats) browses to the local file in PEM or DER formats.
Paste it here (PEM only) pastes the contents of a PEM file.
Decryption Password
Specifies the decryption password, if necessary. Passwords are required for PKCS-12 files, optional for PEM files, and never needed for DER files.
Generate Self-Signed Certificate and New Private Key generates a new private key and self-signed public certificate:
Common Name (required) specifies the hostname of the peer.
Organization Name specifies the organization name (for example, the company).
Organization Unit Name specifies the organization unit name (for example, the section or department).
Locality specifies the city.
State (no abbreviations) specifies the state.
Country (2-letter code) specifies the country (two-letter code only).
Email Address specifies the email address of the contact person.
Validity Period (Days) specifies how many days the certificate is valid. The default value is 730.
Private Key Cipher Bits
Specifies the key length from the drop-down list. The default value is 2048.
Update Certificate Through SCEP Enrollment
Generates a private key and CSR using an SCEP responder. Select the SCEP Management tab to configure the SCEP responder.
Exporting an existing certificate
Under Certificate, select the Export tab. These configuration options are available:
Include Private Key
Includes the private key in the export.
Password/Password Confirm
Specifies and confirms the encrypted password if you are including the private key (required if including the key). The password must be at least four characters.
Export
Exports the SteelHead peering certificate and key.
Generating a CSR
Under Certificate, select the Generate CSR tab. These configuration options are available:
Common Name (required) specifies the common name (hostname) of the peer.
Organization Name specifies the organization name (for example, the company).
Organization Unit Name specifies the organization unit name (for example, the section or department).
Locality specifies the city.
State specifies the state. Do not abbreviate.
Country (2-letter code) specifies the country (two-letter code only).
Email Address specifies the email address of the contact person.
Generate CSR generates the Certificate Signing Request.
Using SCEP to manage the certificate
Under Certificate, select the SCEP Management tab. These configuration options are available:
URL
Specifies the URL of the SCEP responder. Use this format:
http://<host>/<path-to-service>
or
https://<host>/<path-to-service>
Example:
http://<ip-address>/certsrv/mscep/mscep.dll
RiOS 9.5 and later support HTTPS URLs for the SCEP responder. RiOS 8.5 and later support single-tier, two-tier, and three-tier hierarchies to validate the chain certificates it receives.
Maximum Number of Polls
Specifies the maximum number of polls before the SteelHead cancels the enrollment. The peering certificate is not modified. The default value is 5. A poll is a request to the server for an enrolled certificate by the SteelHead. The SteelHead polls only if the server responds with pending. If the server responds with fail then the SteelHead doesn’t poll.
Poll Period
Specifies the poll frequency in minutes. The default value is 5.
Change Challenge Passphrase
Specifies the challenge password phrase.
Enable Auto Enrollment
Enables automatic reenrollment of a certificate to be signed by a CA using SCEP.
Expiration Threshold
Specifies the amount of time (in days) to schedule reenrollment before the certificate expires. The range is from 1 to 60 days. The default value is 30 days.
Update SCEP Settings
Updates the SCEP settings.
Adding or removing a trusted entity
Under Peering Trust, these configuration options are available:
Add a New Trusted Entity
Displays the controls for adding trusted entities.
Trust Existing CA
Specifies an existing CA from the drop-down list.
Trust New Certificate
Adds a new CA or peer certificate. The SteelHead supports RSA and DSA for peering trust entities.
Optional Local Name
Specifies a local name for the entity (for example, the fully qualified domain name).
Local File
Browses to the local file.
Cert Text
Pastes the content of the certificate text file into the text box.
Adding or removing an SCEP trusted entity
Under SCEP Peering Trust, these configuration options are available:
Add a New SCEP Entity
Displays the controls for adding a trusted SCEP entity.
Peering Trust
Specifies a peering trust from the drop-down list.
Adding or removing a SteelCentral Controller for SteelHead Mobile trusted entity
Under Mobile Trust, these configuration options are available:
Add a New Mobile Entity
Displays the controls for adding a trusted SteelCentral Controller for SteelHead Mobile entity.
Optional Local Name
Specifies a local name for the entity (for example, the fully qualified domain name).
Local File
Browses to the local file.
Cert Text
Pastes the content of the certificate text file into the text box.
Changing the trust status of a self-signed peer
To change the trust status of a self-signed peer and move it to another list, or to remove a peer from a list, click the down arrow in the Actions drop-down list. The below configuration options are available.
The white, gray, and black peering lists sort the peers by IP address.
Before moving a peer from the gray list to the trusted peers white list, it is critical to verify that the certificate fingerprint does indeed belong to a peer appliance, particularly to avoid the potential risk of a man-in-the-middle attack.
When the same certificate appears in both the trusted entity and a self-signed peer list, deleting the certificate from one list automatically deletes it from the other.
Restart the optimization service after you apply and save your changes.
Verifying the secure inner channel connections
This section describes what happens when a secure inner channel cannot be established for traffic between appliances and how to verify whether connections are using a secure inner channel.
When the appliances are configured to use secure inner channels for SSL traffic only or All optimized traffic:
• The first connection that runs into a failure is passed through without optimization. This connection appears as established in the Current Connections report, but it is flagged with a red protocol error.
• For up to five minutes all follow-on or subsequent connections are passed through. These follow-on connections appear as pass-through in the Current Connections report. You can click the magnifying glass icon for details about the pass-through reason.
When the appliances are configured to use secure inner channels for SSL and Secure Protocols:
• The first secure protocol connection (either encrypted MAPI, SMB Signed, or Citrix) that runs into a failure is passed through without optimization if Fallback to No Encryption is disabled.
• The first SSL connection that runs into a failure is passed through without optimization. This connection appears as established in the Current Connections report, but it is flagged with a red protocol error.
• For up to five minutes all follow-on or subsequent connections are passed through.
To verify that the secure inner channel is encrypting and optimizing traffic, choose Reports > Networking: Current Connections. 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 connection to view a failure reason that explains why the appliance is not encrypting the connection. If there is a red protocol error, click the connection to view the reason for the error.