SSL Certificates

Deprecation of Reserved and Internal Certificates

In November 2011, the CA/Browser Forum issued guidance deprecating SSL certificates issued for reserved IP addresses or internal domain names. The goal is to remove security concerns by ensuring that the certificate is issued to a globally unique address with an identifiable owner.

What is affected?

All certificates with a Subject Common Name or Subject Alternative Name containing:

• A Reserved IP Address, including RFC1918 addresses such as 10.x.x.x, 192.168.x.x, 172.16-31.x.x etc, but more generally, any address that is not allocated to the customer in the appropriate Regional Internet Registry (RIR).
• An Internal Server Name that is a single word (i.e. has no TLD or extension).
• An Internal Server Name that contains an unregistered domain name that is not resolvable using the public DNS, such as myserver.lan, hostname.local etc, but more generally, any domain name that is not allocated to the customer in the appropriate TLD registry.

Why is this happening?

Certification Authorities enable the establishment of trust on the Internet by issuing certificates that bind cryptographic public key material to verified identities.

The key distinction between the two types of names and addresses is uniqueness. A fully qualified domain name like "www.sargasso.net" represents a unique and distinct identity on the Internet (even if multiple servers respond to that name, the control of that name belongs to a single entity). In contrast, at any given time, there may be thousands of systems on public and private networks that could respond to the unqualified name "www". Only one logical host on the Internet has the IP address "97.74.42.11", while there are tens of thousands of home Internet gateways that have the address "192.168.0.1".

The purpose of certificates issued by publicly trusted Certification Authorities is to provide trust in names across the scope of the entire Internet. Non-unique names, by their very nature, cannot be attested to outside their local context, and such certificates can be dangerously misused, so, as of the effective date of the the guidance, issuance of certificates for non-unique names and addresses, such as "www", "myserver.local", or "192.168.0.1" is deprecated.

But the certificates are only used on our internal network

If there is really no danger on your network, why are you using SSL/TLS at all? The reality is that few networks are truly safe, and if it is necessary to deploy SSL/TLS, it is necessary to do so in a secure manner and to deploy a certificate that meaningfully identifies the host and is not easily impersonated by an attacker – otherwise the encryption is meaningless. Even if you are willing to accept the risk of these certificates for your configuration, the risk they present to the broader ecosystem means their issuance must be discontinued.

For example, suppose that an attacker was issued a certificate for the name "mail". Suppose further that the attacker used this certificate on your network, perhaps redirecting users using local name spoofing. As the certificate is issued by a trusted CA, the attacker can now perfectly impersonate your real mail server and steal users' credentials and other confidential information.

Timeline

November 22, 2011

CA/Browser Forum adopts Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates, Version 1.0

July 1, 2012

Above policy takes effect. Applicants for certificates for Reserved IP Addresses or Internal Server Names will be notified that this practice has been deprecated and will be eliminated by October 2016.

We will no longer issue new certificates to customers but will continue to service and renew existing certificates. Certificates shall have an expiry date no later than November 1, 2015

November 1, 2014

No further certificates will be issued for Reserved IP Addresses or Internal Server Names.

October 1, 2016

All unexpired certificates for Reserved IP Addresses or Internal Server Names will be revoked.

What will be accepted until November 1, 2014?

We will contine to accept certificate requests from existing customers until November 1, 2014 for the following internal uses only:

• IP addresses in ranges that are defined as private and not routed over the Internet, i.e. RFC1918 addresses:
  • 10.0.0.0 - 10.255.255.255 (10/8 prefix)
  • 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
  • 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
• Single-word server names containing no dots, for example:
  • mail
  • sharepoint
• Names with suffixes in the IANA Special-Use Domain Names registry (Note that this includes .local but does not include the commonly-used .lan). Other suffixes will be examined on a case-by-case basis but will probably be denied.

Please note also that if you are using an internal suffix that is not currently a valid TLD, if in the future ICANN makes this a valid public TLD, your certificate will be revoked without notice and without refund.

Furthermore, on March 15, 2013, ICANN issued guidance that, following the approval of a new gTLD for operation, Certification Authorities must within 30 days stop issuing certificates for names that include the new gTLD, and within 120 days must revoke existing certificates including the new gTLD.

Transition

The CA/Browser Forum provides four recommendations for the transition from the use of SSL certificates for Internal Server Names and Reserved IP Addresses, namely:

• Use a fully-qualified domain name certificate and DNS domain suffix search.
• Use an enterprise/private CA to issue and trust certificates for non-unique names.
• Manually provision trust in self-signed certificates.
• Use IPSec

For further information on the above, see the guidance linked at the bottom of this article. Sargasso can provide consultancy services to assist with any of the above migration strategies.

See Also

• Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses - CA/Browser Forum
• SSAC Advisory on Internal Name Certificates - ICANN (PDF)