How Changes to Public Certification Authority Standards Will Affect You

Brass Contributor

May 20, 2019

First published on TECHNET on Mar 20, 2013

Certificates and the public key infrastructure are complex topics, even without having to understand impending change. Changes in the request criteria and format of certificates—subject name, common name, subject alternative name—are coming in November 2015. Although this may sound like the distant future, a certificate is typically valid for 2 years. This means you need to know what the changes are and how they will impact you by November 2013.

Now that I have your attention, let’s look at what’s changing, and what you should plan for in your upcoming deployments and certificate renewal process. I’m going on record here: These are good changes. But I’ll leave the reasons for another article, or for the authorities that have implemented the changes. There is additional information at the end of this article.

Author : Rick Kingslan , Microsoft Senior Technical Writer

Technical Reviewer : Patrick Kelley, Microsoft Consultant

Editor : Susan S. Bradley

Publication date : March 20, 2013

Product version : Affects all software, firmware, and hardware that uses a certificate

The Greek philosopher Heraclitus is credited with the saying, “The only constant is change.” This is usually true—except when it comes to certificates and public key infrastructure (PKI). They provide the basis for key material for cryptographic functions that help to secure deployments, ensure non-repudiation, digitally sign an email, apply computer code verification, and a multitude of other functions. We rely on this solid foundation.

However, the CA/Browser Forum heard of Heraclitus, and in November 2011, they adopted a new set of baseline requirements for publicly trusted certificates that directly affects key factors of certificate planning and may have a huge impact on your Lync Server planning and other certificate uses.

Here’s the first (and potentially most impactful) of the new requirements, as stated by the official announcement from the CA/Browser Forum (bolding mine):

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 .

Effective 1 October 2016 , CAs SHALL revoke all unexpired Certificates whose SAN or Subject Common Name field contains a Reserved IP Address or Internal Server Name .

Public Certification Authorities (CAs) will no longer issue certificates with an expiry date later than November 1, 2015 for domain names that are not officially assigned to a node in the public Domain Name System (DNS) or for IP addresses that reside in the reserved IP address space, defined by the Internet Assigned Numbers Authority.

The accepted and approved top-level domain (TLD) name list changes as need and requirements dictate. Examples of top-level public domain names are:

.com

.net

.edu

.org

.xxx

A complete list is available from Internet Assigned Numbers Authority or IANA, who maintains a database of currently approved TLDs .

What this means is that if you have a domain name that you use for your internal network that does not appear in the official list of TLDs and is not registered to you, you will not be able to request a certificate from a public CA with an expiration date later than November 1, 2015. Most common use certificates expire every two years, and the math is easy from here. More so, if you HAVE a certificate issued by a public CA that uses a TLD or name other than an officially registered name, it will be forcefully expired on October 1, 2016.

For example, let’s assume you are using the internal domain name, contoso.local . A public CA will not issue a certificate for any server in your contoso.local domain, because the .local is not a registered top-level domain. Even if you are using contoso.com internally (where .com is clearly an official TLD), you cannot obtain a certificate from a public CA, because you do not own the domain name contoso.com . If you currently have certificates assigned to computers and issued to the domain contoso.com, they will be expired and made invalid by the issuing public CA on October 1, 2016.

NOTE: This is just an example for you “certificate and TLD savvy” people. You cannot attain a certificate from a public CA for contoso.com.

But, that’s not all. The CA/Browser forum implemented more changes that will affect the way that you request certificates. In some ways, this is actually easier. To see why, let’s first understand the new rules. The baseline requirements issued by the CA/Browser forum contain the following new requirements (summarized here, but you can read the entire requirements online).

Section 9.2.1 Subject Alternative Name Extension

The Subject Alternative Name Extension is a required certificate filed and MUST be populated with at least one entry. The entry type must be either a dNSName containing the fully qualified domain name or an iPAddress containing the IP Address of a server. The CA MUST confirm that the applicant controls the fully qualified domain name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.

At this point, the section on Subject Alternative Names goes on to repeat what we’ve already discussed in above: You can no longer get a certificate for a reserved IP address or non-registered domain name, and on October 1, 2016, all public CAs will revoke any certificates that are still using reserved IP addresses or non-registered domain names.

And there’s more.

Section 9.2.2 Subject Common Name Field

The Subject Common Name field (Certificate Field subject:commonName with an object identifier of 2.5.4.3) is deprecated. The use of this field is discouraged, but not prohibited. If present, the field MUST contain a single IP address or fully qualified domain name that is one of the values contained in the Certificate’s subjectAltName extension (Section 9.2.1)

This is interesting and seemingly ominous at first glance. However, it is not nearly as impactful as the first point. You must abide by the same rules in the first point, but the net of this change is that the Subject Alternative Name (SAN) is now the important attribute field on your certificate, and the Subject/Common Name has been relegated to lessor importance. In fact, you must have the Subject/Common Name appear in the SAN and its use is deprecated and discouraged. Let’s make no mistake—deprecated and discouraged is one step away from being eliminated.

The key takeaway in this section of the new requirements is: Use the Subject Alternative Name entries liberally and don’t count on the Subject/Common Name being around forever.

In fact, the only reason that it’s discouraged and deprecated is to give software, firmware, hardware, and others time to stop using the Subject/Common Name field. They have not gone beyond that, so they likely see this as a longer term issue and more difficult for technical remediation to remove the use of the Subject/Common Name in a predictable timeframe. For example, some certificates—intermediate, issuing, and root certificates—have a 20-year lifetime and the removal of the subject name may be thus problematic.

What you should do – Now

Jeff Schertz, Lync Server MVP, referred to these changes as the “Certificate cliff.” The changes are not overtly drastic, if you use an internal private/enterprise CA (commonly known as an internal public key infrastructure, or PKI). You can use your own certificate—managed and defined however you choose.

The changes outlined are strictly related to certificates issued by a public certification authority and have no impact on what you use your own PKI to do. That said, it is a good idea to mirror the new subject name/common name and subject alternative name guidelines in your own implementation.

It’s difficult to guess if this will become a hard requirement in the future, or if applications will begin to use the new requirements in a strict manner. But, it is better to plan according to standards than to ignore standards and hope that they won’t affect you. Consider Y2K, IPv4, and 32-bit computing for examples of where standards have changed and the early adopters are reaping the benefits of accepting rather than resisting the change.

Summary

In this article, we covered important changes that are either already in place or are coming soon to the publicly available certificate infrastructure that external (Internet) communication relies on for secure communication, encryption, privacy, and non-repudiation. The following is happening now:

The Subject Name / Common Name field is deprecated and discouraged for use.

IP addresses and DNS names not registered with public DNS and IP address authorities are no longer able to acquire public certification authority certificates, affecting external Web server communication over HTTPS, or other communications that require a public certificate.

Public certificates issued after November 1, 2015 must follow these rules.

Public certificates in use on October 1, 2016 will be forcibly expired, requiring the owner to request a new certificate that complies with the rules.

If you need to support an internal domain name or IP address scope that is either not assigned to you or is in the private IP address range for use for private networks, you must use an internal private/enterprise PKI to issue all internal certificates for your user and server purposes.

Hopefully, this article will help you plan for these changes.