The Internet security community is phasing out the use of intranet names and IP addresses as primary domain names or Subject Alternative Names (SANs) in SSL certificates. This is an industry-wide decision, not one specific to our company.

As of July 1, 2012, we no longer accept new requests, rekeys or renewals for SSL certificates that contain intranet names or IP addresses and are valid beyond Nov. 1, 2015. In addition, we do not support SSL certificates that secure public IP addresses or IPv6 addresses.

An intranet name is the name of a private network, such as server1, mail or server2.local, that public Domain Name Servers (DNS) cannot access. An IP address is a string of numbers, such as 123.45.67.890, that defines a computer’s location.

Why the change?

To create a safer online environment, members of the Certificate Authorities Browser Forum met to define implementation guidelines for SSL certificates. As a result, effective October 1, 2016, Certification Authorities (CAs) must revoke SSL certificates that use intranet names or IP addresses.

In short, this change increases security. Because internal server names are not unique, they are vulnerable to man-in-the-middle (MITM) attacks. In a MITM attack, the attacker uses a copy of the real certificate or a duplicate certificate to intercept and retransmit messages. Because CAs issue multiple certificates for the same internal name, an attacker can make a valid request for a duplicate certificate and use it for the MITM.

To read the CA/Browser Forum guidelines, click here.

What action do I need to take?

If you have an existing certificate that contains an intranet name or IP address, you can continue to use that certificate until it expires or until October 1, 2016, whichever comes first. At this time, you can only renew these certificates for a term of one year.

Moving forward, you must seek alternative solutions to secure your intranet names. In other words, instead of securing IP addresses and intranet names, you should reconfigure servers to use Fully Qualified Domain Names (FQDNs), such as www.coolexample.com.

For example, you can create your own Certificate Signing Request (CSR) and use it to sign your SSL certificate. Or, if you use Microsoft® Exchange Server, you can reconfigure its internal AutoDiscover to use a FQDN. For instructions, see Reconfiguring Microsoft Exchange Server to Use a Fully Qualified Domain Name.