This chapter presents a short introduction to basic SSL components and a description of how the components are used in configuring the Secure Content Accelerator. Instructions for generating keys and certificates using the CLI are included in Chapter 4. Instructions for using the GUI are in Chapter 5.

This chapter contains the following sections:

Introduction to SSL

Secure Sockets Layer (SSL) is an application-level protocol that enables secure transactions of data through privacy, authentication, and data integrity. It relies upon certificates, public keys, and private keys.

Certificates are similar to digital ID cards. They prove the identity of the server to clients. Certificates are issued by Certificate Authorities (CAs) such as VeriSign^® or Thawte. Each certificate includes the name of the authority that issued it, the name of the entity to which the certificate was issued, the entity's public key, and time stamps that indicate the certificate's expiration date.

Public and private keys are the ciphers used to encrypt and decrypt information. While the public key is shared quite freely, the private key is never given out. Each public-private key pair works together: data encrypted with the public key can only be decrypted with the private key.

You can configure the Cisco Secure Content Accelerator using either the GUI or CLI, or through the QuickStart wizard (available through both the CLI and GUI). The CLI is available through remote, telnet, or serial connections.

Port Blocking Mechanism

During configuration you must specify the SSL and clear text (decrypted) TCP service ports. Cisco Secure Content Accelerator devices monitor the SSL TCP service port(s) you specify, perform SSL decoding of packets on those ports, then send the packets to the server via a user-defined TCP clear text service port. All other network traffic is passed through the appliance transparently.

The clear text TCP service port used for data transfer between the SSL appliance and the Web server cannot be used for any other data. The SSL appliance blocks access to the clear text port, protecting your secure data from direct clear test access.

One result of this port blocking strategy is that you cannot use the same clear text TCP service port between the SSL appliance and the server for both non-secure (http:) and decrypted secure data (https:) transfer. Network port traffic received on the clear text TCP service port is dropped. See the figures below.

Figure E-1: Port Blocking

Figure E-2: Port Blocking with Dropped Traffic

For example, if the server is used for both secure and non-secure services, you cannot use TCP service port 80 for both basic HTTP connections and for transfer of decrypted secure data between the devices and the server. Below are some alternatives for this scenario.

Use 443 (generally used for SSL transactions) as the SSL TCP service port and 443 as the clear text port. Configure the server to not use SSL and to monitor port 443. TCP service port 80 requests are serviced normally.
Use 443 as the SSL TCP service port and 81 (or another unused port) for the clear text port. Configure the server to monitor port 81. TCP service port 80 requests are serviced normally.

All data sent on any other port is passed through transparently in both directions.

Before You Begin

Before configuring the SSL appliance you must have a certificate and keys for the server. You can use the files you received from the Certificate Authority, copy the keys and certificate from an existing secure server, use default keys and certificates preloaded in the device, or generate your own keys and certificates.

Additionally, be aware that you must make several changes to your Web pages. The nature of the changes depends upon whether you are securing a previously unsecured site, or adding the SSL appliance to an already secure server installation. These changes are described in section "Web Site Changes" in Appendix B.

Using Existing Keys and Certificates

If you already have a secure server, you can transfer the keys and certificate to the Secure Content Accelerator. Follow the instructions below, or refer to the Web server software documentation for detailed information.

Note Key and certificate file names cannot contain spaces and must be compatible with the server operating system. When prompted either to name a key or certificate file or check the name of a key or certificate file, please ensure the names follow these conventions.

Apache mod_SSL

The key and certificate locations are listed in the $APACHEROOT/conf/httpd.conf file. The default key is $APACHEROOT/conf/ssl.key/*.key. The default certificate is $APACHEROOT/conf/ssl.crt/*.crt. Note the name and location of these elements.

ApacheSSL

The key and certificate locations are listed in the $APACHESSLROOT/conf/httpd.conf file. The default key is $APACHEROOT/certs/*.key. The default certificate is $APACHEROOT/certs/*.crt. Note the name and location of these elements.

Stronghold

The key and certificate locations are listed in the $STRONGHOLDROOT/conf/httpd.conf file. The default key is $STRONGHOLDROOT/ssl/private/*.key. The default certificate is $STRONGHOLDROOT/ssl/*.cert. Note the name and location of these elements.

IIS 4 on Windows NT

The certificate file is in the directory specified when the certificate was downloaded.

1. Double-click the certificate file to open the viewer.

2. Click the Details tab.

3. Click Copy to file. The Certificate Manager Export Wizard opens. Click Next.

4. Select the DER-encoded binary X.509 radio button. Click Next.

5. Specify a file name and location. Click Next.

6. Click Finish.

7. Click OK when you see the successful completion notice.

8. Exit the Certificate Manager Export Wizard.

9. Close the certificate viewer.

The keys are located within the Key Ring—the key manager program. Follow these instructions to export a key.

1. Click the Start button, point to Programs>Windows NT 4.0 Option Pack>Microsoft Internet Information Server, and click Internet Service Manager. The Microsoft Management Console opens.

2. Navigate to the Web site using the object list.

3. Right-click the Web site object and click Properties in the shortcut menu.

4. Click the Directory Security tab.

5. Click Edit in the Secure Communication panel.

6. Click Key Manager.

7. Click the key to export.

8. On the Key menu, point to Export Key, and click Backup File.

9. Read the security warning and click OK.

10. Select a file location and enter a file name.

11. Click Save.

12. Exit the Internet Service Manager.

IIS 5 on Windows 2000

Follow these steps to export a certificate and key.

1. Click the Start button, point to Programs>Administrative Tools, and click Internet Service Manager. Alternatively, open the Internet Service Manager in the Administrative Tools folder in the Control Panel.

2. Right-click the Web site object and click Properties in the shortcut menu.

3. Click the Directory Security tab.

4. Click View Certificate in the Secure Communications panel. The Certificate Viewer appears.

5. Click the Details tab.

6. Click Copy to File. The Certificate Export Wizard appears.

7. Click Next. The Export Private Key screen appears.

8. Select the Yes, export the private key option. Click Next. The Export File Format panel appears.

9. Select the Personal Information Exchange—PKCS#12 (pfx) option and any optional choices desired. Click Next. The Password panel appears.

10. Type the password in the Password and Confirm Password text boxes. Click Next. The File to Export panel appears.

11. Type the path and file name in the File name text box or click Browse to select a location manually. Click Next.

12. The Completing the Certificate Export Wizard panel appears. Click Finish.

Note The key and certificate file exported from IIS 5 are in PKCS#12 format. Use the import pkcs12 command in the configuration manager to load a key and certificate in this format.

Configuration Security

Cisco Secure Content Accelerator devices allow easy, flexible configuration without compromising the security of your network or their own configuration.

Cisco SSL Configuration Components

When you configure an appliance to perform SSL offloading you are actually setting up one or more logical secure servers whose SSL-related configurations reside in the appliance. Each logical secure server has several attributes:

A unique IP address and TCP port for the real server providing content
An associated key specifying the public/private key pair to use
A single certificate or certificate group to use
A security policy specifying the cryptographic scheme(s) to use

Real Server IP Addresses

Each SSL server is associated with a specific IP address and TCP port. The address and TCP port are unique and may not be used for more than one SSL server on a single SSL device.

Keys

A single key can be used with each an individual SSL server. You can load multiple keys into the device; however, only one can be used with each SSL server. Keys can be imported from DER- and PEM-encoded X509-format key files, IIS4 backup key-format (NET-IIS), and PKCS#12 files.

Certificates

A certificate is loaded into the device to be used as either a single certificate or part of a certificate group. Only one certificate or certificate group can be used with each server. Certificates can be imported from DER- and PEM-encoded X.509 files, IIS4 backup format (NET-IIS), PKCS#12 files, and PCKS#7 certificate groups.

Step-Up Certificates and Server-Gated Cryptography

Cisco Secure Content Accelerator devices support both Netscape International Step-Up Certificates and Microsoft Server-Gated Cryptography. No special configuration is needed for the device to function properly with these certificates. Load the certificate normally.

Note You must specify that your certificate will work with both Microsoft and Netscape browsers when requesting it from the CA. Otherwise, the server cannot support both browsers.

Chained Certificates

Chained certificates are used in certain circumstances such as when a known, trusted CA (such as Thawte or VeriSign) provides a certificate to attest that certificates created by an intermediary CA can be trusted. For example, a company can create its own certificates for internal use only; however, clients do not accept the certificates because they were not created by a known CA. When private certificates are chained with the trusted CA certificate, clients accept them during SSL negotiations.

The certificate created locally is loaded into the device as a regular certificate; the locally created public/private key pair is loaded into the device as a key. The intermediary CA certificate signed by a trusted CA and any other intermediary certificates are loaded as individual certificate objects that are combined into a certificate group. An example of configuring a chained certificate via the configuration manager is presented in Chapter 5. See Chapter 6 for information about creating and enabling chained certificates using the GUI.

Security Policies

Cisco Secure Content Accelerator can process a wide range of single and composite cryptography schemes. The following table shows a comparison of the individual schemes. If you configure the device to use the weak security policy, all schemes marked as "weak" are used. If you use the strong security policy, all schemes marked as "strong" are used. The "default" security policy uses the encryption and message authentication methods commonly available. The "all" security policy incorporates all listed combinations.

Table E-1: Secure Content Accelerator Cryptographic Algorithms

Cryptographic Scheme	Encryption	Message Authentication	Key Exchange	Security Policy Assignments
ARC4-MD5	ARC4¹ (128)	MD5	RSA (1024)	strong, default, all
ARC4-SHA	ARC4¹ (128)	SHA1	RSA (1024)	strong, default, all
DES-CBC3-MD5	3DES (168)	MD5	RSA (1024)	strong, all
DES-CBC3-SHA	3DES (168)	SHA1	RSA (1024)	strong, fips, all
DES-CBC-MD5	DES (56)	MD5	RSA (1024)	strong, all
DES-CBC-SHA	DES (56)	SHA1	RSA (1024)	strong, fips, all
EXP-ARC2-MD5	ARC2² (40)	MD5	RSA (512)	weak, all
EXP-ARC4-MD5	ARC4¹ (40)	MD5	RSA (512)	weak, default, all
EXP-ARC4-SHA	ARC4¹ (40)	SHA1	RSA (512)	weak, default, all
EXP-DES-CBC-SHA	DES (40)	SHA1	RSA (512)	weak, all
EXP1024-ARC2-CBC-MD5	ARC2² (40)	MD5	RSA (1024)	weak, default, all
EXP1024-ARC4-MD5	ARC4¹ (40)	MD5	RSA (1024)	weak, default, all
EXP1024-ARC4-SHA	ARC4¹ (40)	SHA1	RSA (1024)	weak, default, all
EXP1024-DES-CBC-SHA	DES (40)	SHA1	RSA (1024)	weak, all
NULL-MD5	None	MD5	None	weak, default, all
NULL-SHA	None	SHA1	None	weak, default, all

¹ARC4 is compatible with RC4™ RSA Data Security.
²ARC2 is compatible with RC2™ RSA Data Security.

Cisco Secure Content Accelerator Management

You can configure the Cisco Secure Content Accelerator using one of four methods, three of which use the CLI configuration manager.

Serial connection, configuration manager

An IP address need not have been assigned for appliance management.
A device can be set to single-port mode via serial connection.
A device must be managed while physically connected via a serial cable.
The FailSafe password can be used as a factory reset.

Telnet connection, configuration manager

An IP address must have been assigned to the appliance.
A device cannot be set to single-port mode via telnet.
Only one device can be managed at a time.

Remote network connection, configuration manager application

An IP address need not have been assigned for appliance management.
A device cannot be set to single-port mode via the remote connection.
Multiple devices can be attached.

Remote network connection, GUI

In IP address must have been assigned to the appliance for management.
A device cannot be set to single-port mode via the GUI.
Only one device can be managed at a single time.

Additionally, the behaviors of some commands vary depending upon the management method. The configuration information for the commands ip name-server, rdate-server, and ip domain-name can be set remotely, but the configuration information is used only through a serial or telnet connection. The results of the ping and traceroute commands also are dependent upon the management method. When used with the remote management application, these commands are executed and results returned based upon the configuring computer's hardware information. When used with serial or telnet management, the results are based upon the SSL appliance's hardware information.

Serial and telnet management commands can use symbolic hostnames in URL identifiers if the ip domain-name has been set.

File name formats differ depending on the management method. When using remote management, you can specify the file name as it appears in the configuring computer's file system. A path must be included, if necessary. When using serial or telnet management, the file name must be entered in any of the following formats:

[<

http://   | ftp:// | https:// | tftp:// >] URL

In situations where a file is written, anonymous write access must be configured on the system with these caveats:

http:—The server must be configured to accept PUT commands
https:—The server must be configured to accept PUT commands
ftp:—If anonymous write access is not allowed, use this format:
ftp://username:password@host/directory/filename
tftp:—Use this format:
tftp://host/filename
where the hostname may be either a URL or IP address

Additionally, we provide a guided QuickStart wizard configuration method, available from both the configuration manager and GUI. To use this method for configuration, see Chapter 3. Brief instructions are also included for initiating a management session using the configuration manager.

For instructions on using any of the CLI configuration managers, see Chapter 4; for instructions on using the GUI, see Chapter 5. To use the Secure Content Accelerator in FIPS-compliant operation mode, see Chapter 6.

Table of Contents