After November 1, 2015 Certificates for Internal Names Will No Longer Be Trusted
In November 2011, the CA/Browser Forum (CA/B) adopted Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates that took effect on July 1, 2012. These requirements state:
“As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a Subject Alternative Name (SAN) extension or Subject Common Name field containing a Reserved IP Address or Internal Server Name, the CA shall notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA shall not issue a certificate with an Expiry Date later than 1 November 2015 with a SAN or Subject Common Name field containing a Reserved IP Address or Internal Server Name. As from 1 October 2016, CAs shall revoke all unexpired Certificates.”
The CA/B Forum is a collaborative effort between Certificate Authorities (companies like DigiCert® that issue publicly-trusted certificates) and web browsers (companies like Mozilla or Microsoft that facilitate secure connections).
Because of these new requirements, Certificate Authorities (CAs) must immediately begin to phase out the issuance of SSL Certificates for internal server names or reserved IP addresses and eliminate (revoke) any certificates containing internal names by October 2016. In addition, the baseline requirements prevent CAs from issuing internal name certificates that expire after November 1, 2015. After 2015 it will be impossible to obtain a publicly-trusted certificate for any host name that cannot be externally verified.
These baseline requirements are also being incorporated into global auditing standards. They were included in the WebTrust and ETSI auditing standards for CAs on Jan 1, 2013. Once the requirements are adopted, browsers will require certification from auditors that a CA meets the baseline requirements prior to renewing their root certificate.
What is an Internal Name?
An internal name is a domain or IP address that is part of a private network. Common examples of internal names are:
- Any server name with a non-public domain name suffix. For example, www.contoso.local or server1.contoso.internal.
- NetBIOS names or short hostnames, anything without a public domain. For example, Web1, ExchCAS1, or Frodo.
- Any IPv4 address in the RFC 1918 range.
- Any IPv6 address in the RFC 4193 range.
What Does This Mean for You?
If you are a server admin using internal names, you need to either reconfigure those servers to use a public name, or switch to a certificate issued by an internal CA before the 2015 cutoff date. All internal connections that require a publicly-trusted certificate must be done through names that are public and verifiable (it does not matter if those services are publicly accessible).
Please note that in June 2011, ICANN approved the New Generic Top-Level Domain Program (gTLD) which allows organizations, individuals, and governments to apply for top level namespaces. This will affect many SSL Certificates for internal names before the internal name cutoff date. Read more about the new gTLDs and how they may affect you.
Reconfigure Applications to Not Require Internal Names
Depending on the applications in your environment, you may be able to reconfigure them to not require internal names. And, since the most common use of internal names is in Exchange environments, DigiCert developed a free Internal Name Tool for Microsoft Exchange. This tool is specifically designed to help you reconfigure Exchange’s internal AutoDiscover and service connection points to use publicnames. You do not need a DigiCert certificate to use the tool. Alternatively, you can complete the process manually by following the instructions on this page.