Public CA certificates with Internal Server Names & IP Addresses

padlock

While working on a recent engagement I had a discussion with a customer’s Architect about how we would issue certificates for a vSphere, vRA & vROPS deployment. The customer had no internal CA and relied instead on a public CA to issue all certificates that would be user facing.

This simplified the management of the certificates and meant they did not need to maintain an internal PKI infrastructure or root certificates on client devices. I explained to him that while this worked currently for their servers which used internal names or reserved private IPs it would soon change and they would need to look at deploying their own PKI infrastructure.

As of the 1st November 2015, public Certificate Authorities like Symantec and GlobalSign will no longer issue certificates with a subjectAltName extension or Subject commonName field containing a IP address within the IPv4 RFC 1918 reserved address space or  IPv6 address in the RFC 4193 range:

This is also the case for Internal Names. An Internal Name is a Common Name (CN) or Subject Alternative Name (SAN) field of a certificate  does not end with a valid Top Level Domain (TLD) i.e. .local, .internal etc. CN or SANs which end with valid TLD i.e. .com or .net will still be valid.

This will also affect certificates which use NetBIOS names or short hostnames i.e vCenter01, WebServer, Beeblebrox etc.

Any certificate which expires after the 1st November 2015 will not be reissued and after the 1st October 2016 all certificates which are still valid will be revoked by the issue CAs and will no longer work as a valid certificate.

This is not just a VMware issue and will impact all servers using certificates described above. However, if you are affected by this issue in your VMware environment, VMware have posted a KB article which covers the issue here.

Leave a Reply

Your email address will not be published. Required fields are marked *