Certificate Authorities (CAs) manage certificate requests and issue certificates to participant network devices. Specific CA servers are referred to as trustpoints.
When a connection attempt is made, the secure HTTP (HTTPS) server issues a certified X.509v3 certificate to provide a secure connection. The HTTPS server obtains the certificate from a specified CA trustpoint and issues the certificate to the client. The client (usually a Web browser), in turn, has a public key that enables authentication to the certificate.
For HTTPS connections, Cisco highly recommends the configuration of a CA trustpoint.
If a CA trustpoint is not configured for the device that runs the HTTPS server, the server certifies itself with a self-signed certificate, and generates the necessary Rivest, Shamir, and Adelman (RSA) key pair. A self-signed certificate does not provide adequate security. Therefore, the connecting client generates a notification that the certificate is self-signed, and the user has the option to accept or reject the connection. This option is useful for internal network topologies (for example, testing).
In addition, when a CA trustpoint is not configured, either a temporary or a persistent self-signed certificate for the HTTPS server (or client) is automatically generated when a HTTPS connection is enabled.
For a Cisco Catalyst switch, consider these scenarios:
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 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 the switch reboots or if the HTTPS server is disabled. Therefore, the certificate is available the next time the HTTPS connection is enabled.
The output of the show running-config privileged EXEC command contains information about a self-signed certificate that has been generated.
To remove a self-signed certificate, disable the HTTPS server, and issue the no crypto pki trustpointTP-self-signed-30890755072 global configuration command. If the HTTPS server is enabled later, a new self-signed certificate is generated.
Note: The values that follow TP self-signed depend on the serial number of the device.
The ip http secure-client-auth command is optional. Issue this command to allow the HTTPS server to request an X.509v3 certificate from the client. Authentication of the client provides more security than server authentication.
Hi ALL, Dear Team,we need to understand follow fallback for one of the customer:-Customer is having three Branch Sites and One Data center with dual routers and dual transport (Two MPLS and One Internet). SDWAN Controllers are Cisco-Cloud Hosted. SDW...
Dear experts, I’ll appreciate your comment and advice on the situation we've encountered recently. Our customer’s ASR1001-X router worked just fine until it required rebooting due to maintenance activity. The router refused to boot up (we g...
Hi Guys, I was trying to configure an ASA 5545 and adding it to Tacacs+. I've got the error message "Command authorization failed", once I've pushed this command line: (config)# aaa authentication ssh console tacacs_server LOCALRange already exi...
Since 2008, the ASR 1000 platforms have dramatically changed the WAN edge router’s capabilities. With its very own QuantumFlow Processor (QFP) innovation, the data plane was powered to offer advanced scalable services along with high performance. Fast for...