Administrator Guide
1 An entity or organization that wants a digital certicate requests one through a CSR.
2 To request a digital certicate through a CSR, a key pair is generated and the CSR is signed using the secret private key. The CSR
contains information identifying the applicant and the applicant's public key. This public key is used to verify the signature of the CSR
and the Distinguished Name (DN).
3 This CSR is sent to a Certicate Authority (CA). The CA veries the certicate and signs it using the CA's own private key.
4 The CA then issues the certicate by binding a public key to a particular distinguished name (DN). This certicate becomes the
entity's trusted root certicate.
Advantages of X.509v3 certicates
Public key authentication is preferred over password-based authentication, although both may be used in conjunction, for various reasons.
Public-key authentication provides the following advantages over normal password-based authentication:
• Public-key authentication avoids the human problems of low-entropy password selection and provides more resistance to brute-force
attacks than password-based authentication.
• It facilitates trusted, provable identities—when using certicates signed by trusted CAs.
• It also provides integrity and condentiality in addition to authentication.
X.509v3 support in Dell Networking OS
Dell Networking OS supports X.509v3 standards.
Many organizations or entities need to let their customers know that the connection to their devices and network is secure. These
organizations pay an internationally trusted Certicate Authorities (CAs) such as VeriSign, DigiCert, and so on, to sign a certicate for their
domain.
To implement a X.509v3 infrastructure, Dell Networking OS recommends you to act as your own CA. Common use cases for acting as your
own CA include issuing certicates to clients to allow them to authenticate to a server. For example, Apache, OpenVPN, and so on.
Acting as a certicate authority (CA) means dealing with cryptographic pairs of private keys and public certicates. The rst cryptographic
pair you create is the root pair. This root pair consists of the root key (ca.key.pem) and root certicate—ca.cert.pem. This pair forms the
identity of your CA.
Typically, a root CA does not sign server or client certicates directly. The root CA is only ever used to create one or more intermediate CAs.
These intermediate CAs are trusted by the root CA to sign certicates on their behalf. This is the best practice. It allows the root key to be
kept oine and used to a minimal extent, as any compromise of the root key is disastrous.
For more generic information on setting up your own Certicate Authority (CA), see https://jamielinux.com/docs/openssl-certicate-
authority/index.html#
The following gure illustrates a sample network topology in which a simple X.509v3 infrastructure is implemented:
X.509v3
1139