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.