|
Feature |
Product |
Release introduced |
|---|---|---|
|
Certificate order priority |
5320 Series |
Fabric Engine 8.6 |
|
5420 Series |
VOSS 8.4 |
|
|
5520 Series |
VOSS 8.2.5 |
Use the following information to understand the certificate order priority when the Transport Layer Security (TLS) server and switch connect.
Note
For certain switches in enhanced secure mode, all sensitive files are protected. You cannot access any sensitive files using Telnet, SSH, FTP, SFTP, TFTP, and SCP connections. For more information, see Sensitive File Protection.
The TLS server selects a certificate authority (CA)-signed certificate if the certificate is already installed in the Digital Certificate module.
If the server certificates are not available, the TLS server generates a new self-signed certificate at startup and uses that by default. You can choose to use an online or an offline CA-signed certificate, which takes precedence over the self-signed certificate.
Some early releases use the default certificate available in the /intflash/.ssh folder, which is the open SSL-based self-signed certificate that is named host.cert.
To use the Mocana stack-based self-signed certificate, delete the open SSL self-signed certificate prior to upgrading your software release. The Mocana certificate offers better and stronger encryption than open SSL-based certificates.
If you do not delete the host.cert file in the /intflash/.ssh folder used in earlier releases, you must generate a self-signed certificate automatically during upgrade or post upgrade using the command config ssl certificate.
If you have a subscribed CA-signed certificate renamed as host.cert in folder /intflash/.ssh in a previous release, it cannot be reused.
To use your subscribed CA-signed certificate, upgrade with the Mocana-based self-signed certificate, and then use the digital certificates feature to install a CA-signed certificate through the online or offline method.
You cannot obtain a CA-signed certificate and rename the certificate as host.cert. You must use the online or offline method to obtain a certificate.
If you configure both hostname and domain-name, the self-signed certificate uses hostname.domain-name for both common name (CN) and SAN DNS.
If you configure domain-name but not hostname, the self-signed certificate uses *.domain-name for both CN and SAN DNS.
If you configure hostname but not domain-name, the self-signed certificate uses hostname.extremenetworks.com for both CN and SAN DNS.
If you do not configure either hostname or domain-name, the self-signed certificate uses *.extremenetworks.com for both CN and SAN DNS.
All management IP addresses are added as SAN IP entries.
If you use default self-signed certificates generated in a release that did not include SAN entries in the certificate, generate the certificate again to avoid certificate errors in Web browsers that require these entries.
Note
As a best practice, use custom Public Key Infrastructure (PKI) certificates rather than the default self-signed certificates.