Securing SteelHeads
This section describes security features you can use to harden your network, including ways to secure the SteelHeads and some common sense security policies. This section includes the following topics:
Overview of Securing SteelHeadsBest Practices for Securing Access to SteelHeadsBest Practices for Enabling SteelHead Security FeaturesBest Practices for Policy ControlsBest Practices for Security MonitoringConfiguring SSL Certificates for Web User InterfaceOverview of Securing SteelHeads
Organizations have typically focused attention on securing their networks by providing security for and preventing attacks against hosts. Unfortunately, there are also many security risks associated with networking devices. Attacks against such devices can be used to gather valuable information. For example, an attacker could use tools to fill up the MAC address tables of Ethernet switches, causing the switches to flood packets. These packets might contain passwords that can easily be captured.
The SteelHead has been certified and subsequently deployed for internal use by several highly security-conscious organizations, including military, government, and financial organizations. However, SteelHeads are complex network-facing systems and must be treated accordingly.
Because security requirements vary by organization, consider these recommendations with your particular security goals in mind. Before implementing any security measure described in this section, you must have a thorough understanding of its impact. For example, you do not want to disable access to a SteelHead by mistake and not be able to undo the change because you inadvertently blocked your own access.
If you have a specific security concern, Riverbed recommends that you consult with Riverbed Professional Services.
Best Practices for Securing Access to SteelHeads
This section describes best practices for securing access to your SteelHeads. These practices are not requirements, but Riverbed recommends that you consider these suggestions as implementing them can enforce a secure deployment:
Restrict physical access - You must restrict physical access to any network device. An unauthorized user can easily gain access to a SteelHead if that person has physical access. Every device has the ability to recover lost passwords. By acquiring physical access to a device, an attacker can gain control by using the lost password recovery procedures. Even without breaking into the SteelHead software, it is possible to gain access to the contents of disks by gaining access to the SteelHead itself. You should treat the SteelHead as comparable in value to the servers or clients that hold sensitive data. For example, if servers are in locked rooms, Riverbed recommends the SteelHeads also be in those locked rooms.Someone with physical access could also remove the SteelHead without authorization, allowing an attacker to gain access to confidential data. In general, SteelHeads are less valuable to an attacker than application servers or file servers because of an intrinsic scrambling of the RiOS data store. SteelHeads also support encryption of the RiOS data store to further reduce the likelihood of a successful attack, and SteelCentral Controller for SteelHead Mobile likewise allows the use of file encryption for the RiOS data store on a Window PC.
Physical access increases the susceptibility of the networking device to denial-of-service attacks. A disgruntled employee could conceivably power the SteelHead down, disarrange the cabling, swap hard drives, or even steal the SteelHead.
Use an appropriate login message - The login message appears on the Management Console Home page. You must display a login message that reinforces your organization access and security policies. Have your organization legal council approve an appropriate login message. Typical login messages include, but are not limited to:
statements pertaining to authorized access onlyconsequences of unauthorized accesselimination of right to privacyacknowledgment that the user might be monitoredThe default login message is “Welcome to the Management Console for SteelHead_name!” You can change this message by navigating to the Administration > System Settings: Announcements page in the Management Console and specifying another message. You can also use the CLI as shown in the following example.
Syntax:
[no] banner login <message string>
Example:
banner login. "This computer system is the property of Company XYZ Inc. Disconnect NOW if you have not been expressly authorized to use this system. Unauthorized use is a criminal offence under the Computer Misuse Act 1990.
Communications on or through Company XYZ Inc. computer systems may be monitored or recorded to secure effective system operation and for other lawful purposes.”
Allow management only from the primary interface - Limiting SSH and HTTPS access to the Primary interface allows administrators to restrict who can access the SteelHeads by the use of filters or Access Control Lists. These filters are typically based on the source IP addresses of hosts and are applied on network devices like routers, Layer-3 switches, or firewalls. Limiting remote management access to SteelHeads helps prevent unauthorized user access.Syntax:
[no] web httpd listen enable
[no] web httpd listen interface <interface>
[no] ssh server listen enable
[no] ssh server listen interface <interface>
Example:
web httpd listen enable
web httpd listen interface primary
ssh server listen enable
ssh server listen interface primary
Use SSH version 2 - SSH version 2 is more secure than previous versions of SSH. The major differences between SSH1 and SSH2 fall into two main categories: technical and licensing. SSH2 uses different encryption and authentication algorithms. SSH1 offers four encryption algorithms (DES, 3DES, IDEA, and Blowfish); however, SSH2 dropped support for DES and IDEA but added three algorithms. SSH1 also uses the RSA authentication algorithm; however, SSH2 uses the Digital Signature Algorithm (DSA). These changes were designed to increase the base level of security in SSH2 by using stronger algorithms.
Syntax:
[no] ssh server v2-only enable
Example:
ssh server v2-only enable
Disable unencrypted communication protocols such as Telnet and HTTP - An attacker can easily gain access to usernames and passwords by sniffing network communications. You might consider a switched Ethernet environment secure because packets are only forwarded out ports based on the destination MAC address; however, this is not necessarily the case.Several hacking tools are available that can generate large amounts of bogus MAC addresses. These packets flood the switch's MAC address table in an attempt to overflow the table. A switch typically floods packets out all ports if it does not have an entry in its MAC address table. Therefore, after the MAC address table for the switch is filled, the switch floods packets out all ports.
The attacker can now use a packet-capturing application to capture the flooded packets and can then look for remote management connections. After the attacker discovers remote management connections, the attacker can reset those TCP connections, causing the user to log in again allowing the attacker to capture the username and password.
If only HTTPS and SSH are used, the attacker cannot obtain the usernames and passwords because they are encrypted.
Syntax:
[no] telnet-server enable
[no] web http enable
Example:
no telnet-server enable
no web http enable
In RiOS v8.5 or later, you can configure the SteelHead to redirect HTTP access to HTTPS access with the web http redirect command. Riverbed recommends this method unless your security policy requires the SteelHead to not listen to HTTP.
Use TLS only for the Management Console - Only permit TLS between the browser and the Management Console.Syntax:
web ssl protocol tlsv1
no web ssl protocol sslv3
web ssl protocol tlsv1.1
web ssl protocol tlsv1.2
Restrict user roles - Be sure to restrict the roles of users. For example, if a Help desk administrator is supposed to only view statistics and generate reports, their account restricts them to those roles.Syntax:
[no] rbm user <username> role <role> permissions <permissions>
[no] rbm role <role> primitive <primitive>
Example:
Refer to the Riverbed Command-Line Interface Reference Manual for more information about this command.
Remove the default username from the Web preference settings - The default username in the login field is admin. Do not display a default username because it gives an attacker an example of a username against which to wage a brute-force password attack. Brute-force attacks typically go through an extensive list of words (for example, a dictionary attack) in an attempt to guess the password. Syntax:
web prefs login default
Example:
web prefs login default ""
Change settings for SOAP server - Disable the Simple Object Access Protocol (SOAP) server if it is not in use. You can use the SOAP server to send configuration commands to the SteelHead. Riverbed recommends that you change the port (default TCP port 9001), if you want to enable the SOAP server.Syntax:
[no] web soap-server enable
Example:
no web soap-server enable
Syntax:
[no] web soap-server port <port>
Example:
web soap-server port 1234
Disable unused default accounts - Disable any default accounts that are not in use. The monitor account is disabled by default, unless you upgrade the SteelHead from an earlier release in which the monitor account was enabled. The monitor account is a read-only account that allows you to view all settings, but does not allow you to make any changes.
The shark account allows SteelCentral Packet Analyzer to remotely access TCP dumps on the SteelHead. The shark account allows you to view of all traffic traversing the SteelHead.
Syntax:
[no] username <userid> disable
Example:
username monitor disable
username shark disable
Change all default passwords and community strings - Be sure to change the default password for the administrator, shark, and monitor accounts. The most common problem with SNMP is that it uses the default community string of public. Change the default to something different.
Syntax:
username <userid> password 0 <cleartext_password>
Example:
username admin password 0 o2fMu5TS!
username monitor password 0 o2fMu5TD!
username shark password 0 o2fMu5TP!
Syntax:
[no] snmp-server community <name>
[no] snmp-server trap-community <trap-community-name>
Example:
snmp-server community o2fMu5TS!
Use strong passwords - Strong passwords typically include combinations of letters, numbers, special characters, and combinations of uppercase and lowercase letters with at least eight characters in length. Strong passwords reduce the likelihood of a successful brute-force attack because they are not found in dictionaries and exponentially increase the complexity of the passwords.An example of a strong password is o2fMu5TS!
Use AAA authentication - One of the challenges with using local usernames and passwords is that when an employee leaves an organization, an administrator must touch every device that has a username and password configured for that former employee. By leveraging TACACS+, you gain the advantage of having a single location for configuring usernames and passwords. When a person leaves your organization, you can simply disable that single account thereby preventing the user from access to all of the network devices configured to use TACACS+. Another benefit of TACACS+ is the ability to lock out an account after several unsuccessful login attempts.
TACACS+ also provides greater reporting capabilities regarding who is accessing which devices at what time. With a global username and password, you have no idea which administrator actually logged in at a specific time. These reports can be invaluable for tracking network changes and identifying who is making changes. Therefore, it is a critical tool for change management controls.
Refer to Riverbed Command-Line Interface Reference Manual and the SteelHead Management Console User’s Guide for more detailed information about how to configure AAA.
Configure the CLI session time-out - By default, the SteelHead closes the SSH session to the command line after 15 minutes. You can configure this interval to be more or less with the following command:Syntax:
cli default auto-logout *
Example:
cli default auto-logout 10
This command only affects new SSH sessions. If you want to modify the time-out session only for the current session (and not affect the default settings), use the following command:
Syntax:
cli session auto-logout *
You can disable the auto-logout feature with the following command:
no cli default auto-logout
This command changes both the current and the default settings.
You can display the current auto-logout settings with the following command:
show cli
Use strong SSL ciphers for management communications - Be sure to use strong encryption ciphers for any HTTPS management communications. The cipher is the key that encrypts management communications to the SteelHead. An attacker could still use the hacking tools to crack the encrypted username and password if the encryption ciphers are too weak. An example of a weak cipher is only 56 or 64 bits. A strong cipher is greater than 128 bits.Syntax:
web ssl cipher
Example:
web ssl cipher "HIGH:-aNULL:-kKRB5:-MD5"
Set an inactivity timer for console, SSH, and HTTPS sessions - Be sure to set a proper inactivity time-out value for management sessions. Do not set a console inactivity time-out value to 0. This setting could allow an attacker to take over a previous management session if the previous administrator did not manually log off.Syntax:
[no] web auto-logout <minutes>
[no] cli default auto-logout <minutes>
Example:
web auto-logout 10
cli default auto-logout 10
Ensure SNMP is listening on the management interface only - To prevent unauthorized SNMP access, Riverbed recommends enabling SNMP access on the Primary interface only. This configuration allows administrators to control who can access SteelHeads through SNMP by way of using filters applied to routers, Layer-3 switches, or firewalls.Syntax:
[no] snmp-server listen enable
[no] snmp-server listen interface <interface>
Example:
snmp-server listen enable
snmp-server listen interface Primary
Enable link state alarms - Enable the link state alarms, which are disabled by default. This can alert you to any attempt to modify the cabling on the SteelHeads by inserting a tap for illegal sniffing functions.Syntax:
[no] stats alarm {<type> <options>}
Example:
stats alarm linkstate enable
Disable the auto-discover SCC feature - By default, all SteelHeads try to register with the SCC using the default hostname riverbedscc. If you do not have an SCC, disable this feature. If you do have an SCC, Riverbed recommends that you use it to manually discover SteelHeads, thereby reducing the possibility that an attacker could compromise the DNS environment and change the IP address of the riverbedscc A record to a rogue SCC.
Syntax:
[no] cmc enable
Example:
no cmc enable
Configure a password policy in the SteelHead - In RiOS v8.0 or later, you can configure user accounts on the SteelHead with a password policy to enforce minimum security standards for passwords, number of password attempts, and password expiration. The following password policies are predefined in the SteelHead: Strong security template - Corresponds to the typical recommendations in Federal password guidelines.Basic security template - Provides a minimal set of standards. For more information about the type of accounts, how to configure role-based accounts, and information about the options for the password policy, see the SteelHead Management Console User’s Guide.
Use a BIOS password - Enable a password for BIOS, which prevents admin password recovery without the supervisor password. To configure a BIOS password: Connect a null modem cable to a SteelHead. Open up a terminal on your host to the SteelHead. Power up the SteelHead. Press F4 to enter BIOS. Navigate to the Security tab. Specify a supervisor password. Make sure that the user password option is set to OFF. Save your configuration and continue to boot the SteelHead.Use a boot loader password - When you reboot the SteelHead, you can select from one of the two RiOS images on the menu. You can perform password recovery at this point by pressing the E for edit. Pressing E alters the boot sequence to change the administrative password. Using the following commands, you can enable the boot loader to lock the password recovery process until a password is entered.Steelhead (config) # boot bootloader password test1234
Steelhead (config) # write memory
Steelhead (config) # reload
...
-------------------------------------------------------------------
0: Riverbed Steelhead Software v. 5.5.3 (64bit)
1: Riverbed Steelhead Software v. 5.5.3 (64bit)
-------------------------------------------------------------------
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS or 'p' to enter a
password to unlock the next set of features.
Press 'P'
Password: *******
SSL Issues with Internet Explorer 6 and Oracle R12 - Previously, RiOS fixed a vulnerability found in CBC-based ciphers prior to versions 0.9.6e by inserting an empty frame on the wire to avoid a Chosen Plaintext Attack on cipher-block chaining (CBC) ciphers. Some versions of client and server applications do not understand the insertion of empty frames into the encrypted stream and close the connection when they detect these frames. Therefore, RiOS no longer inserts empty frames by default. Examples of applications that close the connection when they detect these empty frames are IE6 and Oracle R12. SharePoint under IIS has also exhibited this behavior. The failure occurs when the SSL application fails to understand the data payload when either the client or server is using a block cipher using CBC mode as the chosen cipher. This failure can be with DES, AES, or 3DES using CBC. Note that when SteelHeads are deployed, the chosen cipher can be different than when the client is negotiating directly with the SSL server.
Because current Web browsers do not protect themselves from this vulnerability, SteelHeads are no less secure than other vendor’s appliances. From a security perspective, fixing this vulnerability is the responsibility of a server, not a patched client.
To determine whether the SteelHeads are inserting empty frames to avoid an attack, capture TCP dumps on the server-side SteelHead LAN interface and look at the Server Hello message that displays the selected cipher. Verify that DES, AES, or 3DES is the cipher. Also, check for the existence of 32-byte length SSL application data (this is the empty frame) on the LAN traces, followed by an SSL Alert.
To change the default and insert empty frames, enter the CLI command no protocol ssl bug-work-around dnt-insrt-empty.
Best Practices for Enabling SteelHead Security Features
The following best practices enable important security features provided by RiOS. These best practices are not requirements, but Riverbed recommends that you follow these suggestions as implementing them can enforce a secure deployment:
Use peering rules to control enhanced auto-discovery - Enhanced auto-discovery is a feature that allows SteelHeads or SteelHead Mobiles to discover other SteelHeads using TCP options. This feature greatly reduces the complexities and time it takes to deploy SteelHeads. It works so seamlessly that it can occasionally have the undesirable effect of peering with SteelHeads on the Internet that are not in your organization's management domain. Another scenario could be that your organization has a decentralized management approach where different business units might make their own purchasing and management decisions. You might not want SteelHeads from two or more business units to peer with one another.
In these situations, Riverbed recommends using peering rules. Peering rules determine which connections your SteelHead optimizes connections with, based on the source and destination IP addresses or TCP ports. This feature lets you deny peering with any unwanted connections. Another option is to create an Accept peering rule for your corporate network that allows peering from your own IP addresses, and denies it otherwise.
Syntax:
[no] in-path peering rule {auto | pass | accept} peer <peerip> ssl-capability
{cap | in-cap | nocheck] src <subnet> | dest <subnet> | dest-port <port> rulenum <rulenum>
description <desc>
Example:
in-path peering rule accept peer xxx.xxx.xxxx.xxxx/xx
For more information about using peering rules, see the SteelHead Management Console User’s Guide.
Enable a secure inner channel between SteelHeads when using the SMB-signing proxy feature - When sharing files, Windows provides the ability to sign CIFS messages to prevent man-in-the-middle attacks. Each CIFS message has a unique signature which prevents the message from being tampered with. This security feature is called SMB signing. SMB signing is mandatory on all CIFS connections to domain controllers. Therefore, any CIFS connection to a domain controller must use SMB-signed packets.
You can enable the RiOS SMB signing feature on the server-side SteelHeads communicating with servers that have SMB signing set to Required. This alleviates latency in file access with CIFS acceleration while maintaining message security signatures. With SMB signing on, the SteelHead optimizes CIFS traffic by providing bandwidth optimization (RiOS SDR and LZ), TCP optimization, and CIFS latency optimization—even when the CIFS messages are signed.
However, because there is no packet signing taking place between the SteelHeads for these connections, Riverbed recommends that you configure a secure inner channel to encrypt the traffic between the SteelHeads.
Enable a secure inner channel between SteelHeads when using Exchange 2007 encryption - Outlook 2007 has encryption enabled by default. The SteelHeads are able to decrypt this traffic; however, the connections between the SteelHeads are unencrypted by default. Configure a secure inner channel to encrypt all MAPI traffic between the SteelHeads. Enable a secure inner channel to encrypt all optimized traffic between SteelHeads - When you enable a secure inner channel, all data between the client-side and the server-side SteelHeads is sent over the secure inner channel. You configure the peer SteelHead as SSL peers so that they are trusted entities. The SteelHeads authenticate each other by exchanging certificates as part of the encrypted inner-channel setup. After the SteelHeads establish the secure inner channel, you can encrypt and optimize all optimized traffic between SteelHeads using the channel. The trust between the SteelHeads is bidirectional; the client-side SteelHead trusts the server-side SteelHead, and vice versa. Authenticate WCCP service groups - By default, WCCP peers in a WCCP group do not use authentication when registering. This default setting could allow an attacker to join a WCCP group and potentially cause a denial of service attack. Also an administrator could accidentally misconfigure a router to use a WCCP group that already is in use. Authentication controls would prevent these rogue devices from peering, thereby preventing possible network outages or degradation of performance.Syntax:
[no] wccp service-group <service-id> {routers <routers> | assign-scheme [either | hash | mask]
| src-ip-mask <mask> | dst-ip-mask <mask> | src-port-mask <mask> | dst-port-mask <mask>} protocol [tcp | icmp] | encap-scheme [either | gre | l2] | dst-ip-mask <mask> flags <flags> | password <password> | ports <ports> | priority <priority> | weight <weight> | assign-scheme [either | hash | mask] | src-ip-mask <mask> | dst-ip-mask <mask> | src-portmask <mask> | dst-port-mask <mask>}
Example:
wccp service-group 91 routers x.x.x.x password S3cuRity!
Encrypt the RiOS data store - RiOS SDR takes all TCP traffic and segments using a rolling data-driven computation. The segmentation produced is not readily predictable without running the computation, so an attacker interested in reconstructing a particular file does not know how many segments are involved or what the file boundaries are within the segments. The segmentation is stable, so that two identical bit sequences produce the same segmentation. Each new segment identified is written to the RiOS data store, because each previously seen segment is reused.Even though there is inherent security in the obfuscation of the RiOS data store, Riverbed still provides a mechanism for enabling strong encryption of the RiOS data store. Encrypting the RiOS data store significantly limits the exposure of sensitive data in the event an SteelHead is compromised by loss, theft, or other types of security violations. The secured data is impossible for a third party to retrieve.
Syntax:
[no] datastore encryption type {NONE |AES_128 | AES_192 | AES_256}
Example:
datastore encryption type AES_256
Next, select Clear the Data Store on Reboot and reboot the SteelHead.
Change the secure vault - The secure vault contains sensitive information from your SteelHead configuration, including SSL private keys and the RiOS data store encryption key. These configuration settings are encrypted on the disk at all times using AES 256-bit encryption.Initially, the secure vault is keyed with a default password known only to RiOS. This allows the SteelHead to automatically unlock the vault during system startup. You can change the password, but the secure vault does not automatically unlock on start up. To optimize SSL connections or to use RiOS data store encryption, the secure vault must be manually unlocked if the SteelHead is rebooted.
Therefore, Riverbed recommends using this feature only in conjunction with an SCC. The SCC can automatically unlock the Secure Vault when the SteelHead connects to the SCC after a reload.
Syntax:
secure vault {[new-password <password> | reset-password <old password> | unlock <password>]}
Example:
Secure vault unlock o2fMu5TS!
Disable unused features - Disable any features that are not in use. For example, MAPI Exchange is on by default. If your organization uses Lotus Notes, Riverbed recommends that you disable Exchange optimization.Refer to the Riverbed Command-Line Interface Reference Manual or the SteelHead Management Console User’s Guide for the specific features you might want to disable.
Disable automatic email notification - This feature proactively sends email notification of critical issues on the SteelHead (such as significant alarms and events) to Riverbed Support. Your organization might not want to send these automatic notifications.Syntax:
[no] email autosupport enable
Example:
no email autosupport enable
Disable SteelHead reporting - This feature proactively reports some very basic information back to Riverbed Support once a week. This reporting is initially disabled, however, if the user configures name server IP addresses for the SteelHead it is automatically enabled. Your organization might not want to send this report.Syntax:
[no] support uptime-report enable
Example:
no support uptime-report enable
Delete the preconfigured NTP servers - If your organization has NTP configured internally, Riverbed recommends removing the preconfigured NTP servers.Syntax:
[no] ntp server <hostname | ip-address> [version <number>]
Example:
no ntp server 66.187.224.4
Configure Network Time Protocol (NTP) settings - Riverbed recommends that you synchronize the SteelHead to an NTP server of your choice. By default, the appliance uses the Riverbed-provided NTP server. Time is a critical function for the SteelHead and other network devices. Networks rely on accurate time determination for managing, securing, planning, and debugging. Tampering with time sources or posing as a rogue time server can lead to critical issues such as network authentication, or less critical issues such as conflicting log message timestamps. RiOS v8.0 or later supports MD5-based NTP authentication at the CLI, and RiOS v8.5 or later supports both MD5- and SHA-based NTP authentication on the CLI and Management Console.
Disable any interfaces not in use - Be sure to disable any interfaces that are not being used. Examples include the Auxiliary interface and any unused in-path interfaces.Syntax:
[no] interface <interfacename> <options>
Example:
interface inpath0_1 shutdown
For more information about SteelHead security, see the SteelHead Management Console User’s Guide.
Best Practices for Policy Controls
This section includes the best practices for implementing secure policy controls:
Use the Simple Certificate Enrollment Protocol (SCEP) - In RiOS v5.5.2 or later, SCEP allows SteelHeads to request signed certificates for enrollment and reenrollment from the certificate server. Use a Certificate Revocation List (CRL) - In RiOS v5.5.2 or later, SteelHeads can download CRL lists that contain revoked certificates from certificate servers through LDAP. Revoked certificates are considered invalid, and are not used by the SteelHead. For more information about SCEP and CRL, see the SteelHead Deployment Guide - Protocols.
Best Practices for Security Monitoring
After implementing security measures for your organization, Riverbed recommends enabling the following security monitoring features:
Enable Logging - Be sure to enable logging and log to a syslog server. At a minimum, set logging to the notice level to capture failed login attempts. You can also change the default logging facility (CLI only) (system=local0, user=local1, and per-process=local2). Use the CLI command logging facility user local# system local# perprocess local# to configure the syslog facility. Example—A failed login attempt:
Apr 13 05:19:49 BRANCH webasd[6004]: [web.NOTICE]: web: Attempt to Authenticate admin
Apr 13 05:19:49 BRANCH webasd(pam_unix)[6004]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=admin
Apr 13 05:19:49 BRANCH webasd[6004]: [web.NOTICE]: web: Failed to authenticate user admin: You must provide a valid account name and password.
After you enable syslog and log to a server, remember to review the logs daily.
RiOS v6.0 also includes several SNMP traps to notify you of SteelHead configuration changes, successful logins, and system dump initiation. For more information, see the SteelHead Management Console User’s Guide.
Syntax:
[no] logging <IP addr> [trap <log level>]
Example:
logging x.x.x.x trap notice
Email alerts - Be sure to enable email alerts internally.Syntax:
[no] email mailhub <hostname | IP addr>
[no] email notify events enable
[no] email notify failures enable
[no] email notify events recipient <email addr>
[no] email notify failures recipient <email addr>
Example:
email mailhub x.x.x.x
email notify events enable
email notify failures enable
email notify events recipient helpdesk@companyxyz.com
email notify failures recipient helpdesk@companyxyz.com
Refer to the Riverbed Command-Line Interface Reference Manual for more information about configuring email alerts.
Register with the Riverbed forums - Riverbed has several forums that enable you to receive advanced notifications for:general announcements and updatessoftware releasesfeaturesConfiguring SSL Certificates for Web User Interface
The SteelHead automatically generates and uses a self-signed certificate to provide HTTPS access to the Web UI to manage the appliance.
This is separate from the SSL feature set. Management of SSL certificates for the Web UI pertains to the SSL certificate used by the appliance's Web UI when HTTPS is used.
You can replace the self-signed certificate with one created by the administrator or generated by a third-party certificate authority.
To upload a key or certificate
Connect to the SteelHead CLI and enter the following command:web ssl cert import pem <PEM text>
Do not enter more than one certification and more than one key. Because neither is required, you can opt to update only the certificate.
To generate a new certificate for the existing key for use with HTTPS on the SteelHead
Connect to the SteelHead CLI and enter the following command:web ssl cert update
The new certificate is authorized for one year (365 days).
To generate a brand new self-signed certificate and key pair for use with HTTPS management on the SteelHead
Connect to the SteelHead CLI and enter the following command:web ssl cert generate
This command overwrites the existing certificate and key pair regardless of whether the previous one was self-signed or user added. This command generates a self-signed certificate that is authorized for one year (365 days).