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
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
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
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.
authorities and trustpoints must be configured on each device individually.
Copying them from other devices makes them invalid on the switch.
When a new certificate is enrolled, the new configuration change is
not applied to the HTTPS server until the server is restarted. You can restart
the server using either the CLI or by physical reboot. On restarting the
server, the switch starts using the new certificate.
If a self-signed
certificate has been generated, this information is included in the output of
running-config privileged EXEC command. This is a partial sample
output from that command displaying a self-signed certificate.
Controller# show running-config
crypto pki trustpoint 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
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
The values that
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.
information on Certificate Authorities, see the “Configuring Certification
Authority Interoperability” chapter in the
Security Configuration Guide, Release 12.4.