Frequently asked questions about Public Certificate Authority certificates with Internal Server Names and VMware Products

Products

VMware Aria Suite VMware Cloud Director VMware Live Recovery VMware NSX VMware vCenter Server VMware vSphere ESXi

Issue/Introduction

Important: The following does not change normal certificate management for any VMware Product.

Starting November 1, 2015, public Certificate Authorities (CA) will no longer issue certificates with a subjectAltName extension or Subject commonName field containing a Reserved IP Address or Internal Name.

Effective October 1, 2016, CAs will revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name.

This is an agreement by the CA/Browser Forum outlined in the Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates.

Environment

All VMware Products

Resolution

This FAQ should address any questions or concerns users may have relating to this requirement from the CA/Browser Forum.

What is a Reserved IP address?

A Reserved IP address is an IPv4 or IPv6 address that the Internet Assigned Numbers Authority (IANA) has marked as reserved. For more details on what address spaces that IANA has marked as reserved, see:

What is an Internal Name?
An Internal Name is a string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain (TLD) registered in IANA’s Root Zone Database.

If a certificate has been issued where the FQDN ends with a TLD from the Root Zone Database (for example, .com or .net) then it is valid.

However, If a certificate has an FQDN ending in a TLD that is not from the Root Zone Database (for example, .internal or .local) then it may be due to expire on November 1, 2015, and will not be re-issued.

How are VMware products affected?

The following scenarios are not affected:

Default certificate.
VMware Certificate Authority (VMCA) certificates.
Certificates issued by an Internal CA/PKI.
Certificates issued by a Public CA with a subjectAlternativeName extension or Subject commonName containing an FQDN which ends with a TLD from the IANA Root Zone Database.

The following scenarios are affected:

Certificates issued by a Public CA with a subjectAlternativeName extension or Subject commonName containing an FQDN which ends with a TLD that is not from the IANA Root Zone Database.
Certificates issued by a Public CA with a subjectAlternativeName extension or Subject commonName containing a Reserved IP address.

My products are installed on servers using Internal Names and I use public CA certificates. How should I proceed?

If you have VMware products installed on servers using Internal Names, you will no longer be able to use Public CA certificates once the existing certificates have expired. Further, requesting new certificates or having certificates re-issued from the Public CA will not be possible. You are required to implement certificates issued from your own internal CA/PKI. See the Additional Information section for more details
If using Public CA certificates is a requirement for you, then you would need to re-install or re-deploy the respective product with a new FQDN that uses a valid public TLD.

My products are installed on servers using Internal Names and I do not use Public CA certificates for these products, how should I proceed?

If you have VMware products installed on servers using Internal Names and you do not use, Public CA certificates for these products, then no further action is required.

My certificates are not due to expire, what action do I need to take?

If your certificates are not due for expiry on November 1, 2015, and has been issued where the FQDN ends with a TLD that is not in the Root Zone Database, then no action needs to be taken immediately. However, depending on the expiration, the certificates will not be re-issued or will be revoked on October 1, 2016, or the expiry date, whichever comes first.

If your certificates are not due for expiry on November 1, 2015, and has been issued where the FQDN ends with a TLD from the Root Zone Database, then no action needs to be taken immediately.

My certificates are due to expire, what action do I need to take?

If your certificates are due to expire on November 1, 2015, then you will be required to replace these expiring certificates with new valid certificates. See the Additional Information section for more details.

My certificates have expired, what action do I need to take?

If your certificates have expired, then you will be required to replace these certificates with new valid certificates. See the Additional Information section for more details.

How do I obtain new certificates?

Generating new certificates from an internal CA/PKI or obtaining new certificates from a Public CA will need to be handled by the appropriate team or vendor.

A list of Public Certificate Authorities that are members of the CA/Browser Forum can be found here https://cabforum.org/members/.

How do I check my certificates?

For a Windows system:

Locate the certificate that needs to be validated.

Double-Click the certificate.

Navigate to the Details tab.

Verify the Valid to for the expiry date of the certificate.

Verify the Subject field for the value of the CN.

Inspect the Subject Alternative Name field for the value of the DNS Name.

For a Linux system:
1. Run this command to check the validity of the certificate:
  
  openssl x509 -in <path_to_certificate_file> -noout -text | grep -A2 Validity
  
  For example:
  
  openssl x509 -in mycert.crt -noout -text | grep -A2 Validity
  Validity
  Not Before: Oct 14 11:45:32 2015 GMT
  Not After : Oct 13 11:45:32 2017 GMT
2. Run this command to check the Subject field and Value of CN:
  
  openssl x509 -in <path_to_certificate_file> -noout -text | grep Subject:
  
  For example:
  
  openssl x509 -in mycert.crt -noout -text | grep Subject:
  Subject: C=US, O=MyOrg, OU=MyOrg Unit, CN=myserver.mydomain.com
3. Run the following command to check the Subject Alternative Name field and the value of the DNS Name.
  
  openssl x509 -in <path_to_certificate_file> -noout -text | grep -A1 Alternative
  
  For example:
  
  openssl x509 -in mycert.crt -noout -text | grep -A1 Alternative
  X509v3 Subject Alternative Name:
  DNS:myserver.mydomain.com, DNS:myserver

Note: The preceding links were correct as of October 10, 2024. If you find a link is broken, provide a feedback and a Broadcom employee will update the link.