API Guide

The other hosts on the network, such as the SUT switch, syslog server, and OCSP server, generate private keys and create Certificate
Signing Requests (CSRs). The hosts then upload the CSRs to the Intermediate CA or make the CSRs available for the Intermediate CA to
download. Dell Networking OS generates a CSR using the crypto cert generate request command.
The hosts on the network (SUT, syslog, OCSP…) also download and install the CA certificates from the Root and Intermediate CAs. By
installing these CA certificates, the hosts trust any certificates signed by these CAs.
NOTE: You can download and install CA certificates in one step using the crypto ca-cert install command.
The intermediate CA signs the CSRs and makes the resulting certificates available for download through FTP root or otherwise.
Alternatively, the Intermediate CA can also generate private keys and certificates for the hosts. The CA then makes the private key or
certificate 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 certificates. These hosts can also verify
whether they have their own certificates using the private key that they have previously generated.
NOTE: When you use the crypto cert install command to download and install certificates, Dell Networking OS
automatically verifies whether a device has its own certificate.
Now that the X.509v3 certificates are installed on the SUT and Syslog server, these certificates 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 certificates using the CA certificates they installed earlier. The SUT enables Syslog-over-TLS by configuring the
secure keyword in the logging configuration. For example, logging 10.11.178.1 secure 6514.
During the initial TLS protocol negotiation, both participating parties also check to see if the other’s certificate is revoked by the CA. To do
this check, the devices query the CA’s designated OCSP responder on the network. The OCSP responder information is included in the
presented certificate, the Intermediate CA inserts the info upon signing it, or it may be statically configured on the host.
Information about installing CA certificates
Dell Networking OS enables you to download and install X.509v3 certificates from Certificate Authorities (CAs).
In a data center environment, CA certificates are created by trusted hosts on the network. By digitally signing devices' certificates with
the CA's private key, trust can be established among all devices in a network. These CA certificates, installed on each of the devices, are
used to verify certificates presented by clients and servers such as the Syslog servers.
Dell Networking OS enables you to download CA certificates using the crypto ca-cert install command. In this command, you can specify:
• That the certificate is a CA certificate
• The location from which to download the certificate and the protocol with which to do so. For example, tftp://192.168.1.100/
certificates/CAcert.pem. Locations can be usbflash, built-in flash, tftp, ftp, or scp hosts.
After you download a CA certificate, the system verifies the following aspects of the CA certificate:
• The system checks if “CA:TRUE” is specified in the certificate’s extensions section and the keyCertSign bit (bit 5) is set in the
KeyUsage bit string extension. If these extensions are not set, the system does not install the certificate.
• The system checks if the Issuer and Subject fields are the same. If these fields are the same, then the certificate is a self-signed
certificate. These certificates are also called the root CA certificates, as they are not signed by another CA. The system verifies the
certificate with its own public key and install the certificate.
• If the Issuer and Subjects fields differ, then the certificate is signed by another CA farther up the chain. These certificates are also
called intermediate certificates. If a higher CA certificate is installed on the switch, then the system verifies the downloaded certificate
with the CA's public key. The system repeats this process until the root certificate is reached. The certificate is rejected if the
signature verification fails.
• If a higher CA certificate is not installed on the switch, the system rejects the intermediate CA certificate and logs the attempt. The
system also displays a message indicating the reason for the failure of CA certificate installation. The system checks the “not before”
and “not after” fields against the current system date to ensure that the certificate has not expired.
The verified CA certificate is installed on the switch by adding it to an existing file that contains trusted certificates. The certificate is
inserted into the certificate file that stores certificates in a root-last order. Meaning, the downloaded certificate is fit into the file before its
own issuer but following any certificates that it may have issued. This way, the system ensures that the CA certificates file is kept in a
root-last order. The file may contain multiple certificates in PEM format concatenated together. This file is stored in a private and
persistent location on the device such as the flash://ADMIN_DIR folder.
After the CA certificate is installed, the system can secure communications with TLS servers by verifying certificates that are signed by
the CA.
X.509v3
1041