Connectivity Guide

X.509v3 concepts
Certicate A document that associates a network device with its public key. When exchanged between participating devices,
certicates are used to validate device identity and the public key associated with the device. A PKI uses the
following certicate types:
CA certicate: The certicate of a CA that is used to sign host certicates. A CA certicate may be issued by
other CAs or be self-signed. A self-signed CA certicate is called a root certicate.
Host certicate: A certicate that is issued to a network device. A host certicate can be signed by a CA or
self-signed.
Self-signed certicate: A host-signed certicate, compared to a CA-signed certicate.
Certicate authority
(CA)
An entity that veries the contents of a certicate and signs it, indicating that the certicate is trusted and correct.
An intermediate CA signs certicates transmitted between a root CA and a host.
Certicate
revocation list (CRL)
A CA-signed document that contains a list of certicates that are no longer valid, even though they have not yet
expired. For example, when a new certicate is generated for a server, and the old certicate is no longer
supported.
Certicate signing
request (CSR)
After generating a key pair, a switch signs a request to obtain a certicate using its secret private key, and sends
the request to a certicate authority. The CSR contains information that identies the switch and its public key.
This public key is used to verify the private signature of the CSR and the distinguished name (DN) of the switch. A
CSR is signed by a CA and returned to a host for use as a signed host certicate.
Privacy Enhanced
Mail (PEM)
PKI standard used to format X.509v3 data in a secure message exchange; described in RFC 1421.
Public key
infrastructure (PKI)
Application that manages the generation of private and public encryption keys, and the download, installation, and
exchange of CA-signed certicates with network devices.
X.509v3 Standard for the public key infrastructure that manages digital certicates and public key encryption.
Public key infrastructure
To use X.509v3 certicates for secure communication and user authentication on OS10 switches in a network, a public key infrastructure
(PKI) with a certicate authority (CA) is required. The CA signs certicates that prove the trustworthiness of network devices.
When an organization wants to assure customers that the connection to their network is secure, it may pay a commercial Certicate
Authority, such as VeriSign or DigiCert, to sign a certicate for their domain. However, to implement an X.509v3 infrastructure, you can act
as your own CA. While acting as your own CA, you can set up CAs to issue certicates to hosts in the same trusted domain to authenticate
each other.
X.509v3 public key infrastructure
To set up a PKI using X.509v3 certicates, Dell EMC Networking recommends:
1 Congure a root CA that generates a private key and a self-signed CA certicate.
2 Congure one or more intermediate CAs that generate a private key and a certicate signing request (CSR), and send the CSR to the
root CA.
Using its private key, the root CA signs an intermediate CA’s CSR and generates a CA certicate for the Intermediate CA.
The intermediate CA downloads and installs the CA certicate. Afterwards, the intermediate CA can sign certicates for hosts in
the network and for other intermediate CAs that are lower in the PKI hierarchy.
The root and intermediate CA certicates, but not the corresponding private keys, are made publicly available on the network for
network hosts to download.
Whenever possible, store private keys oine or in a location restricted from general access.
828
Security