OS10 supports X.509v3 certificates to secure communications between the switch and a host, such as a RADIUS server. Both the switch and the server exchange a public key in a signed X.509v3 certificate that is issued by a certificate authority (CA) to authenticate each other. The certificate authority uses its private key to sign host certificates.
Generate a certificate signing request and private key
To use X.509v3 certificates for secure communication and user authentication on OS10 switches in a network, a public key infrastructure (PKI) with a certificate authority (CA) is required. The CA signs certificates that prove the trustworthiness of network devices.
Create a private key and a CSR in EXEC mode. Store the CSR file in the home directory or
flash: so that you can later copy it to a CA server. Specify a
keypath to store the
device.key file in a secure persistent location, such as the home directory, or use the
private option to store the key file in a private hidden location in the internal file system that is not visible to users.
OS10# crypto cert generate request cert-file cert-path key-file {private | keypath} country 2-letter code state state locality city organization organization-name orgunit unit-name cname common-name email email-address validity days length length altname alt-name]
request—Create a certificate signing request to copy to a CA.
cert-file
cert-path—(Optional) Enter the local path where the self-signed certificate or CSR is stored. You can enter a full path or a relative path, for example,
flash://certs/s4810-001-request.csr or
usb://s4810-001.crt. If you do not enter the
cert-file option, the system interactively prompts you to enter the remaining fields of the certificate signing request. Export the CSR to a CA using the
copy command.
key-file {key-path | private}—Enter the local path where the downloaded or locally generated private key is stored. If the key was downloaded to a remote server, enter the server path using a secure method, such as HTTPS, SCP, or SFTP. Enter
private to store the key in a local hidden location.
country
2-letter-code—(OPTIONAL) Enter the two-letter code that identifies the country.
state
state—Enter the name of the state.
locality
city—Enter the name of the city.
organization
organization-name—Enter the name of the organization.
orgunit
unit-name—Enter name of the unit.
cname
common-name—Enter the common name that is assigned to the certificate. Common name is the main identity that is presented to connecting devices. By default, the hostname of the switch is the common name. You can configure a different common name for the switch, for example, an IP address. If the
common-name value does not match the identity of the device, a signed certificate does not validate.
email
email-address—Enter a valid email address used to communicate with the organization.
validity
days—Enter the number of days that the certificate is valid. For a CSR, validity has no effect. For a self-signed certificate, the default is 3650 days or 10 years.
length
bit-length—Enter a bit value for the keyword length. For FIPS mode, the range is from 2048 to 4096; for non-FIPS mode, the range is from 1024 to 4096. The default key length for both FIPS and non-FIPS mode is 2048 bits. The minimum key length value for FIPS mode is 2048 bits. The minimum key length value for non-FIPS mode is 1024 bits.
altname
altname—Enter an alternate name for the organization, for example, using the IP address such as
altname IP:192.168.1.100.
The CA server signs the CSR with its private key. The CA server then makes the signed certificate available for the OS10 switch to download and install it.
Install host certificate.
Use the copy command to download an X.509v3 certificate signed by a CA server to the local home directory using a secure method, such as HTTPS, SCP, or SFTP.
Use the
crypto cert install command to install the certificate and the private key that is generated with the CSR.
Generate a certificate signing request and private key
OS10# crypto cert generate request cert-file home://DellHost.pem key-file home://DellHost.key
email admin@dell.com length 1024 altname DNS:dell.domain.com
Processing certificate ...
Successfully created CSR file /home/admin/DellHost.pem and key
OS10# copy home://DellHost.pem scp:///tftpuser@10.11.178.103:/tftpboot/certs/DellHost.pem
password:
OS10# copy scp:///tftpuser@10.11.178.103:/tftpboot/certs/Dell_host1_CA1.pem home://
Dell_host1_CA1.pem
password:
OS10# copy scp:///tftpuser@10.11.178.103:/tftpboot/certs/Dell_host1_CA1.key home://
Dell_host1_CA1.key
password:
OS10# crypto cert install cert-file home://Dell_host1_CA1.pem key-file home://
Dell_host1_CA1.key
Processing certificate ...
Certificate and keys were successfully installed as "Dell_host1_CA1.pem" that may be used in a
security profile. CN = Dell_host1_CA1
Display trusted certificates
The following output displays the installed certificates, the validity period, and details about the CA.
OS10# show crypto cert
--------------------------------------
| Installed non-FIPS certificates |
--------------------------------------
Dell_host1_CA1.pem
--------------------------------------
| Installed FIPS certificates |
--------------------------------------
OS10# show crypto cert Dell_host1_CA1.pem
------------ Non FIPS certificate -----------------
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4096 (0x1000)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = California, O = Dell EMC, OU = Networking, CN = Dell_interCA1
Validity
Not Before: Jul 25 19:11:19 2018 GMT
Not After : Jul 22 19:11:19 2028 GMT
Subject: C = US, ST = California, L = Santa Clara, O = Dell EMC, OU = Networking, CN
= Dell_host1_CA1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:e7:81:4b:4a:12:8d:ce:88:e6:73:3f:da:19:03:
c6:56:01:19:b2:02:61:3f:5b:1e:33:28:a1:ed:e3:
85:bc:56:fb:18:d5:16:2e:a0:e7:3a:f9:34:b4:df:
37:97:93:a9:b9:94:b2:9f:69:af:fa:31:77:68:06:
89:7b:6d:fc:91:14:4a:c8:7b:23:93:f5:44:5a:0a:
3f:ce:9b:af:a6:9b:49:29:fd:fd:cb:34:40:c4:02:
30:95:37:28:50:d8:81:fb:1f:83:88:d9:1f:a3:0e:
49:a1:b3:df:90:15:d4:98:2b:b2:38:98:6e:04:aa:
bd:92:1b:98:48:4d:08:49:69:41:4e:6a:ee:63:d8:
2a:9f:e6:15:e2:1d:c3:89:f5:f0:d0:fb:c1:9c:46:
92:a9:37:b9:2f:a0:73:cf:e7:d1:88:96:b8:4a:84:
91:83:8c:f0:9a:e0:8c:6e:7a:fa:6e:7e:99:3a:c3:
2c:04:f9:06:8e:05:21:5f:aa:6e:9f:b7:10:37:29:
0c:03:14:a0:9d:73:1f:95:41:39:9b:96:30:9d:0a:
cb:d0:65:c3:59:23:01:f7:f5:3a:33:b9:e9:95:11:
0c:51:f4:e9:1e:a5:9d:f7:95:84:9c:25:74:0c:21:
4f:8b:07:29:2f:e3:47:14:50:8b:03:c1:fb:83:85:
dc:bb
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME
Netscape Comment:
OpenSSL Generated Client Certificate
X509v3 Subject Key Identifier:
4A:20:AA:E1:69:BF:BE:C5:66:2E:22:71:70:B4:7E:32:6F:E0:05:28
X509v3 Authority Key Identifier:
keyid:A3:39:CB:C7:76:86:3B:05:44:34:C2:6F:90:73:1F:5F:64:55:5C:76
X509v3 Key Usage: critical
Generate a self-signed certificate
Administrators may prefer to not set up a Certificate Authority and implement a certificate trust model in the network, but still want to use the privacy features provided by the Transport Layer Security (TLS) protocol. In this case, self-signed certificates can be used.
A self-signed certificate is not signed by a CA. The switch presents itself as a trusted device in its certificate. Connecting clients may prompt their users to trust the certificate—for example, when a web browser warns that a site is unsafe—or to reject the certificate, depending on the configuration. A self-signed certificate does not provide protection against man-in-the-middle attacks.
Create a self-signed certificate in EXEC mode. Store the
device.key file in a secure, persistent location, such as NVRAM.
If you enter the cert-file option, you must enter all the required parameters, including the local path where the certificate and private key are stored. If you do specify the cert-file option, you are prompted to enter the other parameter values for the certificate interactively, for example:
You are about to be asked to enter information that will be incorporated in your
certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank.
For some fields there will be a default value; if you enter '.', the field will be left
blank.
Country Name (2 letter code) [US]:
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:San Francisco
Organization Name (eg, company) []:Starfleet Command
Organizational Unit Name (eg, section) []:NCC-1701A
Common Name (eg, YOUR name) [hostname]:S4148-001
Email Address []:scotty@starfleet.com
Install a self-signed certificate and key file in EXEC mode.
cert-file
cert-path specifies a source location for a downloaded certificate, for example,
home://s4048-001-cert.pem or usb://s4048-001-cert.pem.
key-file {key-path | private} specifies the local path to retrieve the downloaded or locally generated private key. Enter private to install the key from a local hidden location and rename the key file with the certificate name.
password
passphrase specifies the password that is used to decrypt the private key if it was generated using a password.
fips installs the certificate-key pair as FIPS-compliant. Enter
fips to install a certificate-key pair that is used by a FIPS-aware application, such as RADIUS over TLS. If you do not enter
fips, the certificate-key pair is stored as a non-FIPS compliant pair.
NOTE:You determine if the certificate-key pair is generated as FIPS-compliant. Do not use FIPS-compliant certificate-key pairs outside of FIPS mode.
If you enter
fips after using the
key-file private option in the
crypto cert generate request command, a FIPS-compliant private key is stored in a hidden location in the internal file system that is not visible to users.
If the certificate installation is successful, the file name of the self-signed certificate and its common name are displayed. Use the file name to configure the certificate in a security profile using the
crypto security-profile command.
Example: Generate and install self-signed certificate and key
OS10# crypto cert generate self-signed cert-file home://DellHost.pem key-file home://
DellHost.key email admin@dell.com length 1024 altname DNS:dell.domain.com validity 365
Processing certificate ...
Successfully created certificate file /home/admin/DellHost.pem and key
OS10# crypto cert install cert-file home://DellHost.pem key-file home://DellHost.key
Processing certificate ...
Certificate and keys were successfully installed as "DellHost.pem" that may be used in a
security profile. CN = DellHost.
Display self-signed certificate
OS10# show crypto cert
--------------------------------------
| Installed non-FIPS certificates |
--------------------------------------
DellHost.pem
--------------------------------------
| Installed FIPS certificates |
--------------------------------------
OS10# show crypto cert DellHost.pem
------------ Non FIPS certificate -----------------
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 245 (0xf5)
Signature Algorithm: sha256WithRSAEncryption
Issuer: emailAddress = admin@dell.com
Validity
Not Before: Feb 11 20:10:12 2019 GMT
Not After : Feb 11 20:10:12 2020 GMT
Subject: emailAddress = admin@dell.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:c7:12:ca:a8:d6:d2:1c:ab:66:9a:d1:db:50:5a:
b5:8a:e4:53:9d:f6:b4:fc:cd:f4:b9:46:8a:03:86:
be:0b:50:51:c7:25:76:9f:ff:b4:f9:f8:d9:6f:5d:
53:52:0c:4d:05:ed:31:23:79:44:5c:d7:62:01:9d:
41:e8:ff:3a:b0:35:0c:22:d7:ef:df:05:9a:28:6b:
95:10:8e:bc:c6:62:3a:82:30:0f:4f:4e:19:17:48:
f1:bd:1e:0c:4f:54:03:42:f3:a7:de:22:40:3d:5e:
6b:b2:8e:23:17:53:ef:10:d9:ae:1d:1f:d6:e4:ae:
25:9f:d9:39:60:5c:49:b0:ad
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
DA:39:A3:EE:5E:6B:4B:0D:32:55:BF:EF:95:60:18:90:AF:D8:07:09
X509v3 Subject Alternative Name:
DNS:dell.domain.com
Signature Algorithm: sha256WithRSAEncryption
b8:83:ae:34:bb:84:e6:b4:a3:fd:77:20:67:15:3f:02:76:ca:
f6:74:d4:d2:36:0e:58:8c:96:13:c2:85:8a:df:ba:c0:d9:c8:
Certificate revocation
A certificate revocation list (CRL) is a list of digital certificates that have been revoked by the issuing certificate authority (CA) before their scheduled expiration date. These certificates are no longer meant to be trusted.
Before the switch and an external device, such as a RADIUS or TLS server, set up a secure connection, they present CA-signed certificates to each other. The certificate validation allows peers to authenticate each other's identity, and is followed by checking to ensure that the certificate has not been revoked by the issuing CA.
A certificate includes the URL and other information about the certificate distribution point (CDP) that issued the certificate. Using the URL, OS10 accesses the CDP to download a certificate revocation list (CRL). If the external device's certificate is on the list or if the CDP server does not respond, the connection is not set up.
Configure the URL for a certificate distribution point in EXEC mode.
OS10# crypto cdp add cdp-namecdp-url
Verify the CDPs accessed by the switch in EXEC mode.
OS10# show crypto cdp [cdp-name]
To delete an installed CDP, use the
crypto cdp delete
cdp-name command.
Install CRLs that have been downloaded from CDPs in EXEC mode.
OS10# crypto crl install crl-path [crl-filename]
Display a list of the CRLs installed on the switch in EXEC mode.
OS10# show crypto crl [crl-filename]
To delete a manually installed CRL that was configured with the
crypto crl install command, use the
crypto crl delete [crl-filename] command.
The following displays a list of revoked certificates:
OS10# show crypto crl COMODO_Certification_Authority.0.crl.pem
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/
CN=COMODO Certification
Authority
Last Update: May 8 20:34:21 2019 GMT
Next Update: May 12 20:34:21 2019 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:0B:58:E5:8B:C6:4C:15:37:A4:40:A9:30:A9:21:BE:47:36:5A:56:FF
X509v3 CRL Number:
2904
No Revoked Certificates.
Signature Algorithm: sha1WithRSAEncryption
5b:77:52:c0:a0:4e:77:be:4a:c4:6a:7e:92:98:2e:a1:6b:3c:
ad:2d:ac:db:0a:19:1d:a3:56:98:7f:d6:93:f3:1d:4b:61:40:
c3:e0:40:45:0b:41:4b:66:87:35:2b:3a:4c:f3:f1:7e:44:7e:
fe:7f:51:5d:17:ee:b3:4c:15:75:a6:a0:7b:2e:b1:92:3e:b6:
71:a8:01:8d:78:ac:80:3b:16:f2:f1:a8:fd:09:68:9f:7e:09:
55:c6:80:2c:2f:e7:f3:54:51:94:3a:d8:b4:d6:00:3f:63:b1:
19:f3:42:2a:d2:c4:3b:de:c4:4d:ad:f0:72:c5:b4:25:51:e5:
3c:76:8b:97:3c:db:fe:3f:7f:41:d2:d9:aa:7f:98:90:6b:cf:
27:53:0e:66:83:8e:cc:81:ef:6a:e5:cd:c2:f1:e2:ea:84:4f:
73:bb:90:5a:b3:19:a3:50:6a:c7:b3:99:e4:09:fd:56:99:83:
3a:15:93:b0:4a:49:28:78:69:85:de:fc:06:cc:b9:a5:5b:d9:
4a:b0:46:90:ce:94:3a:9c:f3:04:e4:d7:98:36:29:a8:8b:fe:
72:26:b0:fd:39:5e:14:f5:00:6d:0e:4f:ec:d4:a5:ca:4f:e1:
d9:4f:5a:37:21:e3:a2:fb:80:db:cd:68:0b:a0:fa:58:0d:5e:
40:e1:e4:1c
Configure security profiles
To use independent sets of security credentials for different OS10 applications, you can configure multiple security profiles and assign them to OS10 applications. A security profile consists of a certificate and private key pair.
For example, you can maintain different security profiles for RADIUS over TLS authentication and SmartFabric services. Assign a security profile to an application when you configure the profile.
When you install a certificate-key pair, both take the name of the certificate. For example, if you install a certificate using:
The certificate-key pair is installed as
Dell_host1.pem and
Dell_host1.key. In configuration commands, enter the pair as
Dell_host1. When you configure a security profile, you enter
Dell_host1 in the
certificate certificate-name command.
Create an application-specific security profile in CONFIGURATION mode.
Assign a certificate and private key pair to the security profile in SECURITY-PROFILE mode. For
certificate-name, enter the name of the certificate-key pair as it appears in the
show crypto certs output without the
.pem extension.
(Optional) Enable CRL checking for certificates received from external devices in SECURITY-PROFILE mode. CRL checking verifies the validity of a certificate using the CRLs installed on the switch.
OS10(config-sec-profile)#revocation-check
(Optional) Enable peer name checking for certificates presented by external devices in SECURITY-PROFILE mode. Peer name checking ensures that the certificate matches the name of the peer device, such as a remote server name.
OS10(config-sec-profile)#peer-name-check
Use the security profile to configure X.509v3-based service, for example, to configure RADIUS over TLS authentication using an X.509v3 certificate, enter the
radius-server host tls command:
OS10 allows you to use Common Access Card (CAC) and Personal Identity Verification (PIV) smart cards for authenticating users when connecting to the device with SSH. CAC and PIV smart cards contain Public Key Infrastructure (PKI) X.509v3 certificates that are issued by certificate authorities. This feature allows the OS10 software to verify user authentication and email signing and encryption. To use smart card authentication, use an SSH client that supports X.509v3 authentication.
Although users can use strong and complex passwords for secure access to their devices, people tend to write their passwords down or store them in unsecured locations. Using a smart card for SSH improves security such that users need not memorize complex passwords.
The OS10 SSH server supports X.509v3 smart card authentication in two forms - with or without a password. When you use X.509v3 authentication with passwords, you can use X.509v3 authentication along with remote authentication using RADIUS or TACACS+ authentication.
Remote user authentication with a password
When you configure the switch for X.509v3 SSH authentication and remote authentication of users using RADIUS or TACACS+, and when connecting using SSH, the following sequence occurs:
Insert a CAC or PIV smart card into the card reader slot in your system or keyboard.
Start an RFC 6187 X.509v3 compatible SSH client application, set authentication to smart card or CAC, and make a connection to the OS10 switch.
The SSH client application makes the initial connection to the switch, negotiates X.509v3 authentication, and validates the OS10 switch X.509v3 certificate.
The SSH client application prompts you to select the required authentication certificate from the CAC or PIV card.
The SSH client application prompts you to enter the PIN for the CAC or PIV card.
The SSH client application sends an authentication request with your X.509v3 certificate.
The OS10 SSH server validates the public certificate, including validating the trust chain, valid date range, and usage fields. If any of the fields are invalid, the authentication fails.
If the configured OS10 security profile calls for revocation checking, the OS10 SSH server verifies that the certificate is not revoked. Verification is done by checking either the appropriate CRL or by sending an OCSP request to the appropriate OCSP responder.
If the certificate is revoked, the authentication fails.
If peer-name-checking is enabled in the security profile, the OS10 SSH server matches the common name or principal name fields from the user certificate against the username. The authentication fails if there is no match.
The OS10 SSH server prompts you for a password.
The OS10 SSH server performs standard RADIUS or TACACS+ user authentication using the username and returned password.
On successful authentication, the SSH session continues.
Local user authentication with a password
When you configure the OS10 SSH server for X.509v3 SSH local authentication and when you connect using SSH, the following sequence occurs:
Insert a CAC or PIV smart card into the card reader slot in your computer or keyboard.
Start an RFC 6187 X.509v3 compatible SSH client application, set authentication to smart card or CAC, and make a connection to the OS10 switch.
The SSH client application makes the initial connection to the switch, negotiates X.509v3 authentication, and validates the X.509v3 certificate.
The SSH client application prompts you to select the required authentication certificate from the CAC or PIV card.
The SSH client application prompts you to enter the PIN for the CAC or PIV card.
The SSH client application sends an authentication request with the X.509v3 certificate.
The OS10 SSH server validates the public certificate, including validating the trust chain, valid date range, and usage fields. If any of the fields are invalid, the authentication fails.
If the configured OS10 security profile calls for revocation checking, the OS10 SSH server verifies that the certificate is not revoked. Verification is done by checking either the appropriate CRL or by sending an OCSP request to the appropriate OCSP responder.
If the certificate is revoked, the authentication fails.
If peer-name-checking is enabled in the security profile, the OS10 SSH server matches the common name or principal name fields from the user certificate against the username.
If there is no match, the OS10 SSH server attempts to match the user certificate fields against any configured certificate for that local username.
If there is no match, the authentication fails.
The OS10 SSH server prompts you for a password.
The OS10 SSH server performs standard local user authentication using the username and returned password.
On successful authentication, the SSH session continues.
Local user authentication without a password
When you configure OS10 SSH server for X.509v3 SSH local authentication, and when connecting using SSH, the following sequence occurs:
Insert a CAC or PIV smart card into the card reader slot in your computer or keyboard.
Start an RFC 6187 X.509v3 compatible SSH client application, set authentication to smart card or CAC, and make a connection to the OS10 switch.
The SSH client application makes the initial connection to the switch, negotiates X.509v3 authentication, and validates the OS10 switch X.509v3 certificate.
The SSH client application prompts you to select the required authentication certificate from the CAC or PIV card.
The SSH client application prompts you to enter the PIN for the CAC or PIV card.
The SSH client application sends an authentication request with the X.509v3 certificate.
The OS10 SSH server validates the public certificate, including validating the trust chain, valid date range, and usage fields. If any of the fields are invalid, the authentication fails.
If the configured OS10 security profile calls for revocation checking, the OS10 SSH server verifies that the certificate is not revoked. Verification is done by checking either the appropriate CRL or by sending an OCSP request to the appropriate OCSP responder.
If the certificate is revoked, the authentication fails.
The OS10 SSH server attempts to match the user certificate fields against the configured certificate for that local username.
If there is a match, the authentication succeeds and the SSH session proceeds without a password prompt.
Configure remote user authentication with a password
To support remote user authentication by smart card and password, configure the following:
ip ssh server x509v3-authentication security-profile profile-name
If all SSH login attempts require an X.509v3 certificate, disable the plain password authentication and SSH public key authentication in the SSH server.
no ip ssh server password-authentication
no ip ssh server pubkey-authentication
Configure local user authentication with a password
To support local user authentication by smart card and password, configure the following:
Enable X.509v3 authentication in the SSH server.
ip ssh server x509v3-authentication security-profile profile-name
If all SSH login attempts present an X.509v3 certificate, disable the plain password authentication and SSH public key authentication in the SSH server.
no ip ssh server password-authentication
no ip ssh server pubkey-authentication
If you enable the key-usage-check in the security profile but the user certificates use a different name syntax than the user login names, configure the user certificate details to allow the SSH server to match the user certificate to the account.
username username certificate subject “x509v3-subject-string”
or
username username certificate principal-name user-principal-name-string
or
username username certificate fingerprint fingerprint-value
Configure local user authentication without a password
To support password-less local user authentication using a smart card and password, configure the following:
Enable password-less X.509v3 authentication in the SSH server.
ip ssh server x509v3-authentication security-profile profile-name password-less
Leave plain password authentication enabled for users that do not have a configured certificate.
ip ssh server password-authentication
Leave plain public key authentication enabled if it is required that users can alternatively use SSH public key password-less authentication.
ip ssh server pubkey-authentication
Configure the user X.509v3 certificate details to allow the SSH server to match the user certificate to the account.
username username certificate subject “x509v3-subject-string”
or
username username certificate principal-name user-principal-name-string
or
username username certificate fingerprint fingerprint-value
Generate and install a new security certificate on OS10 10.4.3.0 and later releases for full switch mode
Switches running on OS 10.5.0.7P3 and previous supported releases, that have VLT or SmartFabric Services enabled, use secure channels to communicate with each other. To establish secure channels, OS10 uses X.509v3 certificates.
When a user logs in to the system, OS10 images from 10.4.3.x to 10.5.0.7P3 display a warning message that the cluster manager is using the default credentials.
Configuration notes:
Even if you reinstall OS10, the certificate is present on the system. If you reinstall OS10, reinstall the certificate by removing and readding the security profile using the
no cluster security-profile and the
cluster security-profile
profile-name commands.
Use the following procedure to install a valid certificate so that the system stops displaying the warning message and continues to function properly. This procedure only works for OS10 releases 10.4.3.0 and later. If you are running OS10 releases between 10.4.1.4 and 10.4.2.x, upgrade to a later release.
Verify the OS10 version on both devices.
Switch-A:
Switch-A# show version
Dell EMC Networking OS10 Enterprise
Copyright (c) 1999-2020 by Dell Inc. All Rights Reserved. OS Version: 10.5.0.7P3
Build Version: 10.5.0.7.745
Build Time: 2020-06-02T22:46:24+0000
System Type: MX9116N-ON
Architecture: x86_64
Up Time: 00:07:32
Switch-B:
Switch-B# show version
Dell EMC Networking OS10 Enterprise
Copyright (c) 1999-2020 by Dell Inc. All Rights Reserved. OS Version: 10.5.0.7P3
Build Version: 10.5.0.7.745
Build Time: 2020-06-02T22:46:24+0000
System Type: MX9116N-ON
Architecture: x86_64
Up Time: 00:08:10
Verify if the system is in full switch mode.
Switch-A:
Switch-A# show switch-operating-mode
8713-ToR-2# Switch-Operating-Mode : Full Switch Mode
Switch-B:
Switch-B# show switch-operating-mode
8713-ToR-2# Switch-Operating-Mode : Full Switch Mode
Verify if VLT is converged.
Switch-A:
Switch-A# show vlt 255
Domain ID : 255
Unit ID : 1 Role : primary
Version : 2.3
Local System MAC address : 20:04:0f:20:86:00
Role priority : 32768
VLT MAC address : 20:04:0f:21:9a:00
IP address : fda5:74c8:b79e:1::1
Delay-Restore timer : 90 seconds
Peer-Routing : Disabled
Peer-Routing-Timeout timer : 0 seconds
VLTi Link Status
port-channel1000 : up
VLT Peer Unit ID System MAC Address Status IP Address Version
----------------------------------------------------------------------------------
2 20:04:0f:21:9a:00 up fda5:74c8:b79e:1::2 2.3
Switch-B:
Switch-B# show vlt 255
Domain ID : 255
Unit ID : 2 Role : secondary
Version : 2.3
Local System MAC address : 20:04:0f:21:9a:00
Role priority : 32768
VLT MAC address : 20:04:0f:21:9a:00
IP address : fda5:74c8:b79e:1::2
Delay-Restore timer : 90 seconds
Peer-Routing : Disabled
Peer-Routing-Timeout timer : 0 seconds
VLTi Link Status
port-channel1000 : up
VLT Peer Unit ID System MAC Address Status IP Address Version
----------------------------------------------------------------------------------
1 20:04:0f:20:86:00 up fda5:74c8:b79e:1::1 2.3
Create a self-signed certificate using the OS10 CLI. You can do this on one of the switches in the same VLT domain or SmartFabric Cluster.
Switch-A:
Switch-A# crypto cert generate self-signed cert-file home://dell.crt key-file home://dell.ky cname sfscert
Processing file ...
Successfully created certificate file and key
You can also specify the following parameters:
country
2-letter-code — (OPTIONAL) Enter the two-letter code that identifies the country.
state
state — Enter the name of the state.
locality
city — Enter the name of the city.
organization
organization-name — Enter the name of the organization.
orgunit
unit-name — Enter name of the unit.
cname
common-name — Enter the common name assigned to the certificate. Common name is the main identity that is presented to connecting devices. By default, the host name of the switch is the common name. You can configure a different common name for the switch, for example, an IP address. If the
common-name value does not match the device’s presented identity, a signed certificate does not validate.
email
email-address — Enter a valid email address used to communicate with the organization.
validity
days — Enter the number of days that the certificate is valid. For a self-signed certificate, the default is 3650 days.
length
bit-length — Enter a bit value for the keyword length. For FIPS mode, the range is from 2048 to 4096; for non-FIPS mode, the range is from 1024 to 4096. The default key length for both FIPS and non-FIPS mode is 2048 bits. The minimum key length value for FIPS mode is 2048 bits. The minimum key length value for non-FIPS mode is 1024 bits.
altname
altname — Enter an alternate name for the organization, for example, using the IP address such as
altname IP:192.168.1.100.
Verify if the newly created certificates are present in the home directory.
Switch-A:
Switch-A# dir home
Directory contents for folder: home
Date (modified) Size (bytes) Name
--------------------- ------------ --------------------------------------
2020-12-18T14:20:32Z 1017 dell.crt 2020-12-18T14:20:32Z 1675 dell.ky
Copy the certificate and key from Switch-A to an SCP server. In this example, SCP is used but you can also use a TFTP or FTP server.
NOTE:All devices in the SFS cluster or VLT domain must have the same certificate and key files.
Verify if the certificate is copied to Switch- B.
Switch-B:
Switch-B# dir home
Directory contents for folder: home
Date (modified) Size (bytes) Name
--------------------- ------------ ------------------------------------------
2020-12-18T14:59:51Z 1017 dell.crt 2020-12-18T15:00:42Z 1675 dell.ky
(Only if you are running release 10.4.3.x) Create the
store folder under the /config/certs/ directory on both devices.
Switch-A# system "sudo mkdir /config/certs/store"
Switch-B# system "sudo mkdir /config/certs/store"
Copy the certificate to the /config/certs/store/ location and run the
c_rehash command on both VLT peers.
Switch-A# system "sudo cp /config/certs/dell.crt /config/certs/store/"
Switch-A# system "sudo c_rehash /config/certs/store/"
Switch-B# system "sudo cp /config/certs/dell.crt /config/certs/store/"
Switch-B# system "sudo c_rehash /config/certs/store/"
Open a new SSH session and verify that the warning messages are not displayed. Even if the new certificate is not in effect on the VLT domain or SFS cluster, the system does not generate the warning message.
For MX devices, reboot one of the VLT peers in each VLT pair and the SFS primary node if you are running a multinode cluster deployment. For non-MX devices, flap the VLTi link.
CAUTION:Flapping the VLTi link or rebooting the node may lead to transient packet loss. Perform this step during a maintenance window.
(Optional) Verify if VLT is converged.
Switch-A:
Switch-A# show vlt 255
Domain ID : 255
Unit ID : 1
Role : primary
Version : 2.3
Local System MAC address : 20:04:0f:20:86:00
Role priority : 32768
VLT MAC address : 20:04:0f:21:9a:00
IP address : fda5:74c8:b79e:1::1
Delay-Restore timer : 90 seconds
Peer-Routing : Disabled
Peer-Routing-Timeout timer : 0 seconds
VLTi Link Status
port-channel1000 : up
VLT Peer Unit ID System MAC Address Status IP Address Version
----------------------------------------------------------------------------------
2 20:04:0f:21:9a:00 up fda5:74c8:b79e:1::2 2.3
Switch-B:
Switch-B# show vlt 255
Domain ID : 255
Unit ID : 2
Role : secondary
Version : 2.3
Local System MAC address : 20:04:0f:21:9a:00
Role priority : 32768
VLT MAC address : 20:04:0f:21:9a:00
IP address : fda5:74c8:b79e:1::2
Delay-Restore timer : 90 seconds
Peer-Routing : Disabled
Peer-Routing-Timeout timer : 0 seconds
VLTi Link Status
port-channel1000 : up
VLT Peer Unit ID System MAC Address Status IP Address Version
----------------------------------------------------------------------------------
1 20:04:0f:20:86:00 up fda5:74c8:b79e:1::1 2.3
Data is not available for the Topic
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please select whether the article was helpful or not.
Comments cannot contain these special characters: <>()\
