Concept Guide

The Root CA generates a private key and a self-signed CA certicate.
The Intermediate CA generates a private key and a Certicate Signing Request (CSR).
Using its private key, the root CA signs the intermediate CA’s CSR generating a CA certicate for the Intermediate CA. This intermediate
CA can then sign certicates for hosts in the network and also for further intermediate CAs. These CA certicates (root CA and any
intermediate CAs), but not the corresponding private keys, are made publicly available on the network.
NOTE
: CA certicates may also be bundled together for ease of installation. Their .PEM les are concatenated in order from the
“lowest” ranking CA certicate to the Root CA certicate. handles installation of bundled certicate les.
The other hosts on the network, such as the SUT switch, syslog server, and OCSP server, generate private keys and create Certicate
Signing Requests (CSRs). The hosts then upload the CSRs to the Intermediate CA or make the CSRs available for the Intermediate CA to
download. generates a CSR using the crypto cert generate request command.
The hosts on the network (SUT, syslog, OCSP…) also download and install the CA certicates from the Root and Intermediate CAs. By
installing these CA certicates, the hosts trust any certicates signed by these CAs.
NOTE
: You can download and install CA certicates in one step using the crypto ca-cert install command.
The intermediate CA signs the CSRs and makes the resulting certicates available for download through FTP root or otherwise.
Alternatively, the Intermediate CA can also generate private keys and certicates for the hosts. The CA then makes the private key or
certicate pairs available for each host to download. You can password-encrypt the private key for additional security and then decrypt it
with a password using the crypto cert install command.
The hosts on the network (SUT, syslog, OCSP…) download and install their corresponding signed certicates. These hosts can also verify
whether they have their own certicates using the private key that they have previously generated.
NOTE
: When you use the crypto cert install command to download and install certicates, automatically veries whether a
device has its own certicate.
Now that the X.509v3
certicates are installed on the SUT and Syslog server, these certicates can be used during TLS protocol
negotiations so that the devices can verify each other’s trustworthiness and exchange session keys to protect session data. The devices
verify each other’s certicates using the CA certicates they installed earlier. The SUT enables Syslog-over-TLS by conguring the
secure keyword in the logging conguration. For example, logging 10.11.178.1 secure 6514.
X.509v3
1247