Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
This section describes how to configure Secure Sockets Layer (SSL) Version 3.0 support for the HTTP 1.1 server and client. SSL provides server authentication, encryption, and message integrity, as well as HTTP client authentication, to allow secure HTTP communications.
Note
SSL evolved into Transport Layer Security (TLS) in 1999, but is still used in this particular context.
On a secure HTTP connection, data to and from an HTTP server is encrypted before being sent over the Internet. HTTP with SSL encryption provides a secure connection to allow such functions as configuring a switch from a Web browser. Cisco's implementation of the secure HTTP server and secure HTTP client uses an implementation of SSL Version 3.0 with application-layer encryption. HTTP over SSL is abbreviated as HTTPS; the URL of a secure connection begins with https:// instead of http://.
The primary role of the HTTP secure server (the switch) is to listen for HTTPS requests on a designated port (the default HTTPS port is 443) and pass the request to the HTTP 1.1 Web server. The HTTP 1.1 server processes requests and passes responses (pages) back to the HTTP secure server, which, in turn, responds to the original request.
The primary role of the HTTP secure client (the web browser) is to respond to Cisco IOS application requests for HTTPS User Agent services, perform HTTPS User Agent services for the application, and pass the response back to the application.
For configuration examples and complete syntax and usage information for the commands used in this section, see the “HTTPS - HTTP Server and Client with SSL 3.0” feature description for Cisco IOS Release 12.2(15)T.
Certificate authorities (CAs) manage certificate requests and issue certificates to participating network devices. These services provide centralized security key and certificate management for the participating devices. Specific CA servers are referred to as trustpoints.
When a connection attempt is made, the HTTPS server provides a secure connection by issuing a certified X.509v3 certificate, obtained from a specified CA trustpoint, to the client. The client (usually a Web browser), in turn, has a public key that allows it to authenticate the certificate.
For secure HTTP connections, we highly recommend that you configure a CA trustpoint. If a CA trustpoint is not configured for the device running the HTTPS server, the server certifies itself and generates the needed RSA key pair. Because a self-certified (self-signed) certificate does not provide adequate security, the connecting client generates a notification that the certificate is self-certified, and the user has the opportunity to accept or reject the connection. This option is useful for internal network topologies (such as testing).
If you do not configure a CA trustpoint, when you enable a secure HTTP connection, either a temporary or a persistent self-signed certificate for the secure HTTP server (or client) is automatically generated.
If the switch is not configured with a hostname and a domain name, a temporary self-signed certificate is generated. If the switch reboots, any temporary self-signed certificate is lost, and a new temporary new self-signed certificate is assigned.
If the switch has been configured with a host and domain name, a persistent self-signed certificate is generated. This certificate remains active if you reboot the switch or if you disable the secure HTTP server so that it will be there the next time you re-enable a secure HTTP connection.
Note
The certificate authorities and trustpoints must be configured on each device individually. Copying them from other devices makes them invalid on the switch.
If a self-signed certificate has been generated, this information is included in the output
of the show running-config privileged EXEC command. This is a
partial sample output from that command displaying a self-signed certificate.
You can remove this self-signed certificate by disabling the secure HTTP server and
entering the no crypto pki trustpoint TP-self-signed-30890755072
global configuration command. If you later re-enable a secure HTTP server, a new
self-signed certificate is generated.
Note
The values that follow TP self-signed depend on the serial number of the device.
You can use an optional command (ip http secure-client-auth) to
allow the HTTPS server to request an X.509v3 certificate from the client. Authenticating
the client provides more security than server authentication by itself.
For additional information on Certificate Authorities, see the “Configuring Certification
Authority Interoperability” chapter in the Cisco IOS Security Configuration Guide,
Release 12.4.
CipherSuites
A CipherSuite specifies the encryption algorithm and the digest algorithm to use on a SSL connection. When connecting to the HTTPS server, the client Web browser offers a list of supported CipherSuites, and the client and server negotiate the best encryption algorithm to use from those on the list that are supported by both. For example, Netscape Communicator 4.76 supports U.S. security with RSA Public Key Cryptography, MD2, MD5, RC2-CBC, RC4, DES-CBC, and DES-EDE3-CBC.
For the best possible encryption, you should use a client browser that supports 128-bit encryption, such as Microsoft Internet Explorer Version 5.5 (or later) or Netscape Communicator Version 4.76 (or later). The SSL_RSA_WITH_DES_CBC_SHA CipherSuite provides less security than the other CipherSuites, as it does not offer 128-bit encryption.
The more secure and more complex CipherSuites require slightly more processing time. This list defines the CipherSuites supported by the switch and ranks them from fastest to slowest in terms of router processing load (speed):
SSL_RSA_WITH_DES_CBC_SHA—RSA key exchange (RSA Public Key Cryptography) with DES-CBC for message encryption and SHA for message digest
SSL_RSA_WITH_RC4_128_MD5—RSA key exchange with RC4 128-bit encryption and MD5 for message digest
SSL_RSA_WITH_RC4_128_SHA—RSA key exchange with RC4 128-bit encryption and SHA for message digest
SSL_RSA_WITH_3DES_EDE_CBC_SHA—RSA key exchange with 3DES and DES-EDE3-CBC for message encryption and SHA for message digest
RSA (in conjunction with the specified encryption and digest algorithm combinations) is used for both key generation and authentication on SSL connections. This usage is independent of whether or not a CA trustpoint is configured.
Default SSL Configuration
The standard HTTP server is enabled.
SSL is enabled.
No CA trustpoints are configured.
No self-signed certificates are generated.
SSL Configuration Guidelines
When SSL is used in a switch cluster, the SSL session terminates at the cluster commander. Cluster member switches must run standard HTTP.
Before you configure a CA trustpoint, you should ensure that the system clock is set. If the clock is not set, the certificate is rejected due to an incorrect date.
In a switch stack, the SSL session terminates at the stack master.
Secure HTTP Servers and Clients Overview
On a secure HTTP connection, data to and from an HTTP server is encrypted before being sent over the Internet. HTTP with SSL encryption provides a secure connection to allow such functions as configuring a switch from a Web browser. Cisco's implementation of the secure HTTP server and secure HTTP client uses an implementation of SSL Version 3.0 with application-layer encryption. HTTP over SSL is abbreviated as HTTPS; the URL of a secure connection begins with https:// instead of http://.
The primary role of the HTTP secure server (the switch) is to listen for HTTPS requests on a designated port (the default HTTPS port is 443) and pass the request to the HTTP 1.1 Web server. The HTTP 1.1 server processes requests and passes responses (pages) back to the HTTP secure server, which, in turn, responds to the original request.
The primary role of the HTTP secure client (the web browser) is to respond to Cisco IOS application requests for HTTPS User Agent services, perform HTTPS User Agent services for the application, and pass the response back to the application.
How to Configure Secure HTTP Servers and Clients
Configuring a CA Trustpoint
For secure HTTP connections, we recommend that you configure an official CA trustpoint. A CA trustpoint is more secure than a self-signed certificate.
Beginning in privileged EXEC mode, follow these steps to configure a CA Trustpoint:
SUMMARY STEPS
1.configureterminal
2.hostnamehostname
3.ip domain-namedomain-name
4.crypto key generate rsa
5.crypto ca trustpointname
6.enrollment urlurl
7.enrollment http-proxyhost-name port-number
8.crlqueryurl
9.primaryname
10.exit
11.crypto ca authenticationname
12.crypto ca enrollname
13.end
DETAILED STEPS
Command or Action
Purpose
Step 1
configureterminal
Example:
Switch# configure terminal
Enters the global configuration mode.
Step 2
hostnamehostname
Example:
Switch(config)# hostname your_hostname
Specifies the hostname of the switch (required only if you have not previously configured a hostname). The hostname is required for security keys and certificates.
Step 3
ip domain-namedomain-name
Example:
Switch(config)# ip domain-name your_domain
Specifies the IP domain name of the switch (required only if you have not previously configured an IP domain name). The domain name is required for security keys and certificates.
Step 4
crypto key generate rsa
Example:
Switch(config)# crypto key generate rsa
(Optional) Generates an RSA key pair. RSA key pairs are required before you can obtain a certificate for the switch. RSA key pairs are generated automatically. You can use this command to regenerate the keys, if needed.
Step 5
crypto ca trustpointname
Example:
Switch(config)# crypto ca trustpoint your_trustpoint
Specifies a local configuration name for the CA trustpoint and enter CA trustpoint configuration mode.
Configures the switch to request a certificate revocation list (CRL) to ensure that the certificate of the peer has not been revoked.
Step 9
primaryname
Example:
Switch(ca-trustpoint)# primary your_trustpoint
(Optional) Specifies that the trustpoint should be used as the primary (default) trustpoint for CA requests.
For name, specify the trustpoint that you just configured.
Step 10
exit
Example:
Switch(ca-trustpoint)# exit
Exits CA trustpoint configuration mode and return to global configuration mode.
Step 11
crypto ca authenticationname
Example:
Switch(config)# crypto ca authentication your_trustpoint
Authenticates the CA by getting the public key of the CA. Use the same name used in Step 5.
Step 12
crypto ca enrollname
Example:
Switch(config)# crypto ca enroll your_trustpoint
Obtains the certificate from the specified CA trustpoint. This command requests a signed certificate for each RSA key pair.
Step 13
end
Example:
Switch(config)# end
Returns to privileged EXEC mode.
Configuring the Secure HTTP Server
Beginning in privileged EXEC mode, follow these steps to configure a secure HTTP server:
Before You Begin
If you are using a certificate authority for certification, you should use the previous procedure to configure the CA trustpoint on the switch before enabling the HTTP server. If you have not configured a CA trustpoint, a self-signed certificate is generated the first time that you enable the secure HTTP server. After you have configured the server, you can configure options (path, access list to apply, maximum number of connections, or timeout policy) that apply to both standard and secure HTTP servers.
To verify the secure HTTP connection by using a Web browser, enter https://URL, where the URL is the IP address or hostname of the server switch. If you configure a port other than the default port, you must also specify the port number after the URL. For example:
(Optional) Displays the status of the HTTP server to determine if the secure HTTP server feature is supported in the software. You should see one of these lines in the output:
HTTP secure server capability: Present
or
HTTP secure server capability: Not present
Step 2
configure terminal
Example:
Switch# configure terminal
Enters global configuration mode.
Step 3
ip http secure-server
Example:
Switch(config)# ip http secure-server
Enables the HTTPS server if it has been disabled. The HTTPS server is enabled by default.
Step 4
ip http secure-portport-number
Example:
Switch(config)# ip http secure-port 443
(Optional) Specifies the port number to be used for the HTTPS server. The default port number is 443. Valid options are 443 or any number in the range 1025 to 65535.
Step 5
ip http secure-ciphersuite {[3des-ede-cbc-sha]
[rc4-128-md5] [rc4-128-sha]
[des-cbc-sha]}
Example:
Switch(config)# ip http secure-ciphersuite rc4-128-md5
(Optional) Specifies the CipherSuites (encryption algorithms) to be used for encryption over the HTTPS connection. If you do not have a reason to specify a particularly CipherSuite, you should allow the server and client to negotiate a CipherSuite that they both support. This is the default.
Step 6
ip http secure-client-auth
Example:
Switch(config)# ip http secure-client-auth
(Optional) Configures the HTTP server to request an X.509v3 certificate from the client for authentication during the connection process. The default is for the client to request a certificate from the server, but the server does not attempt to authenticate the client.
Step 7
ip http secure-trustpointname
Example:
Switch(config)# ip http secure-trustpoint your_trustpoint
Specifies the CA trustpoint to use to get an X.509v3 security certificate and to authenticate the client certificate connection.
Note
Use of this command assumes you have already configured a CA trustpoint according to the previous procedure.
Step 8
ip http pathpath-name
Example:
Switch(config)# ip http path /your_server:80
(Optional) Sets a base HTTP path for HTML files. The path specifies the location of the HTTP server files on the local system (usually located in system flash memory).
Step 9
ip http access-classaccess-list-number
Example:
Switch(config)# ip http access-class 2
(Optional) Specifies an access list to use to allow access to the HTTP server.
Step 10
ip http max-connectionsvalue
Example:
Switch(config)# ip http max-connections 4
(Optional) Sets the maximum number of concurrent connections that are allowed to the HTTP server. The range is 1 to 16; the default value is 5.
Step 11
ip http timeout-policyidlesecondslifesecondsrequestsvalue
Example:
Switch(config)# ip http timeout-policy idle 120 life 240 requests 1
(Optional) Specifies how long a connection to the HTTP server can remain open under the defined circumstances:
idle—the maximum time period when no data is
received or response data cannot be sent. The range is 1 to 600 seconds. The
default is 180 seconds (3 minutes).
life—the maximum time period from the time that
the connection is established. The range is 1 to 86400 seconds (24 hours).
The default is 180 seconds.
requests—the maximum number of requests processed
on a persistent connection. The maximum value is 86400. The default is
1.
Step 12
end
Example:
Switch(config)# end
Returns to privileged EXEC mode.
Configuring the Secure HTTP Client
Beginning in privileged EXEC mode, follow these steps to configure a secure HTTP client:
Before You Begin
The standard HTTP client and secure HTTP client are always enabled. A certificate authority is required for secure HTTP client certification. This procedure assumes that you have previously configured a CA trustpoint on the switch. If a CA trustpoint is not configured and the remote HTTPS server requires client authentication, connections to the secure HTTP client fail.
Switch(config)# ip http client secure-trustpoint your_trustpoint
(Optional) Specifies the CA trustpoint to be used if the remote HTTP server requests client authentication. Using this command assumes that you have already configured a CA trustpoint by using the previous procedure. The command is optional if client authentication is not needed or if a primary trustpoint has been configured.
Step 3
ip http client secure-ciphersuite {[3des-ede-cbc-sha]
[rc4-128-md5] [rc4-128-sha]
[des-cbc-sha]}
Example:
Switch(config)# ip http client secure-ciphersuite rc4-128-md5
(Optional) Specifies the CipherSuites (encryption algorithms) to be used for encryption over the HTTPS connection. If you do not have a reason to specify a particular CipherSuite, you should allow the server and client to negotiate a CipherSuite that they both support. This is the default.
Step 4
end
Example:
Switch(config)# end
Returns to privileged EXEC mode.
How to Configure Secure HTTP Servers and Clients
These sections contain this configuration information:
Monitoring Secure HTTP Server and Client Status
To monitor the SSL secure server and client status, use the privileged EXEC commands in the following table.
Table 1 Commands for Displaying the SSL Secure Server and Client Status
Command
Purpose
show ip http client secure status
Shows the HTTP secure client configuration.
show ip http server secure status
Shows the HTTP secure server configuration.
show running-config
Shows the generated self-signed certificate for secure HTTP connections.