The DNS name is not included in the Subject Alternative Names (SAN) of the NSX-T Manager certificate.

Products

• VMware NSX

Issue/Introduction

• When an NSX Manager appliance is deployed or reconfigured with a hostname that contains only one period (e.g:- nsx-manager.local, myhost.corp, controller.test), the auto-generated self-signed certificate issued by the NSX Manager does not include the FQDN in the SAN field instead it shows only the "IP address" configured for the appliance, or only one of the names the cert is used meant to be used with.

          

   

• This omission can lead to certificate warnings or errors in web browsers and can present the same certificate to the remaining NSX Managers attempting to connect using its FQDN, as the FQDN used for access does not match any name listed in the certificate. While the IP address might be present, relying on it is not a recommended long-term solution.

Environment

Product: VMware NSX
Versions Affected: NSX-T 4.2.1.0 and later
Component: NSX Manager Appliance Certificate Management

Cause

Modern Public Key Infrastructure (PKI) standards and best practices, as well as many application security implementations (including NSX Manager's certificate generation logic), discourage or explicitly disallow the use of:

• Single-Label DNS Names: Hostnames without any periods (e.g:- nsxmgr).
• Names Resembling Top-Level Domains (TLDs): Such as .local, .corp, or .test, which are not globally resolvable and are often considered special-use domains (e.g., .local is defined by RFC 6762 for mDNS/Bonjour).
• The NSX Manager appliance, adhering to these security best practices, implements internal validation rules for hostname parsing and certificate generation. When the configured FQDN (e.g:- nsx-manager.local) falls into this problematic category, the NSX Manager's certificate generation process may omit the FQDN from the Subject Alternative Name (SAN) field, considering it an invalid or non-standard entry for a robust certificate.
• The NSX manager won't include the FQDN in the auto-generated cert if it has only one period. The reason for this is when we generate a self-signed cert we populate it with a wildcard DNS name and wildcard DNS names with a single period are not considered valid.
• This behavior is not due to the system attempting to create an invalid wildcard certificate (e.g:- *.local). Instead, it is a consequence of the FQDN itself being deemed non-standard or problematic for certificate SAN inclusion due to the strictness of modern PKI and application security requirements. Valid wildcard certificates require at least two periods (e.g:- *.example.com).
• Some certs (such as the one used for managers) may be issued for multiple hosts. In this case, the SAN field should contain all the FQDN's and IP's that may match this cert. Note, as of NSX 4.2.x there are 2 separate SAN fields, one for IP's, and one for FQDN's. 

Resolution

•  The recommended approach to address this issue is to use the NSX Manager self signed certificate generated using the Fully Qualified Domain Name (or a name with at least two periods e.g:- "world.globe.local")
• Enter all possible alternate names for this cert in the SAN fields, both FQDN style, and IP. 

Additional Information

• For additional information on PKI infrastructure, please refer the below link:
  https://en.wikipedia.org/wiki/Public_key_certificate#Wildcard_certificate