Knowledge Base

All publicly trusted SSL Certificates issued to internal names and reserved IP addresses
will expire before November 1, 2015.

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:

• CAs should notify applicants before issuance that use of certificates with a Subject Alternative Name (SAN) extension or a Subject Common Name field containing a reserved IP address or internal server name has been deprecated by the CA/B
• CAs should not issue a certificate with an expiration date later than November 1, 2015, with a SAN or Subject Common Name field containing a reserved IP address or an internal server Name

For more information, click here.

Background

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).

The baseline requirements prevent CAs from issuing internal name certificates that expire after November 1, 2015. It will be impossible to obtain a publicly trusted certificate for any hostname that cannot be externally verified after 2015.

These requirements also dictate that Certificate Authorities (CAs) must immediately begin to phase out issuance of SSL Certificates for internal server names or reserved IP addresses and eliminate (revoke) any certificates containing internal names. CA/B requires CAs to revoke any certificates containing internal names by October 2016.

These baseline requirements are also being incorporated into global auditing standards. They were included in the WebTrust and ETSI auditing standards for CAs on January 1, 2013. Once the requirements are adopted, browsers will require certification from auditors that a CA meets the baseline requirements before renewing its root certificate.
 

What is an Internal Name?

An internal name is a domain or IP address that's 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 public names. 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.