Certificate Order Priority

Table 1. Certificate order priority product support
Feature	Product	Release introduced
Certificate order priority	5320 Series	Fabric Engine 8.6
	5420 Series	VOSS 8.4
	5520 Series	VOSS 8.2.5
	5720 Series	Fabric Engine 8.7
	7520 Series	Fabric Engine 8.10
	7720 Series	Fabric Engine 8.10
	VSP 4450 Series	VOSS 5.1.2
	VSP 4900 Series	VOSS 8.1
	VSP 7200 Series	VOSS 5.1.2
	VSP 7400 Series	VOSS 8.0
	VSP 8200 Series	VOSS 5.1.2
	VSP 8400 Series	VOSS 5.1.2
	VSP 8600 Series	Not Supported
	XA1400 Series	VOSS 8.0.50

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.

SSL-Based 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.

SAN Entries in Default TLS Certificates

The default TLS certificates add hostname.domainname and management IP address as subject alternative name (SAN) entries:

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.