Cisco Systems 3130 User Manual

Page of 1226
 
7-43
Cisco Catalyst Blade Switch 3130 for Dell Software Configuration Guide
OL-13270-01
Chapter 7      Configuring Switch-Based Authentication
Configuring the Switch for Secure Socket Layer 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. 
Certificate Authority Trustpoints
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. 
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.
Switch# show running-config
Building configuration...
<output truncated>
crypto pki trustpoint TP-self-signed-3080755072
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-3080755072
 revocation-check none
 rsakeypair TP-self-signed-3080755072
!
!
crypto ca certificate chain TP-self-signed-3080755072
 certificate self-signed 01
  3082029F 30820208 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
  59312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
  69666963 6174652D 33303830 37353530 37323126 30240609 2A864886 F70D0109
  02161743 45322D33 3535302D 31332E73 756D6D30 342D3335 3530301E 170D3933
  30333031 30303030 35395A17 0D323030 31303130 30303030 305A3059 312F302D