GlobalSign Blog

Upcoming Changes to Publicly Trusted TLS Certificates

Upcoming Changes to Publicly Trusted TLS Certificates

Editor's Note: This blog has been updated on June 9, 2021 to provide additional information about the changes to ECC key usage and the thought process behind them.

The CA/Browser Forum and Root programs specify requirements that CAs must comply with and be audited against to provide uniform requirements across all CAs and to protect web site visitors by setting important compliance and security requirements. You are all aware that the maximum validity for TLS certificates was reduced from 5 years to 3 years to 825 days and just last September, down to 397 days (about 13 months). In this post, we’d like to inform you of some of the upcoming changes that have been mandated by the Root programs and/or the CAB Forum.

CA SHALL verify Domain Names and IP Addresses no more than 398 days prior to Certificate issuance

Effective date: October 1, 2021

Last September, Apple mandated a 398-day max validity period, but the domain and organizational validation reuse period remained at 825 days. This is the second shoe dropping on that change. This reduction in the domain re-use period has been expected and is unlikely to be the last. This stems from several studies that found in certain cases, during domain ownership changes, the existing certificates can continue to be replaced/re-issued from the prior CA. One way to remedy that is to reduce the domain validation re-use period.

Take a step back and think about the situation this way:

  • Up until the Apple mandated reduction in maximum validity, the time between domain validation and certificate expiration was 825 + 825 days, or about 4 1/2 years. That’s a long time!
  • With Apple’s reduction in max validity, the difference is 825+398 days which is still more than 3 years
  • With this latest change, the max difference is 398+398, or just a bit over 2 years.
  • For comparison purposes, the CA that issues the most certificates per year, Let’s Encrypt, issues certificates with a max validity of 90 days and they re-use domain validation for a max of 30 days, or a max of 4 months between validation and certificate expiration.

We can expect the industry to drive towards the Let’s Encrypt baseline and eventually even shorter than that.

Prohibit the HTTP domain validation method for issuance of subdomains and wildcards

Effective Date: December 1, 2021

The HTTP domain validation method (officially known as method 6, Agreed-Upon Change to Website) is commonly used to verify domain control. If you can place a file at a specific directory of the web site it “demonstrates” control over that domain. Unlike DNS, websites don’t have the same controls where there is a formal delegation of permissions from the domain to subdomains. So, if example.com got hacked, or its owner had certain malicious tendencies, they can approve example.com and then issue certs to subdomains. But those subdomains might be different entities, and again, since there is not the same level of formal delegation of control, Mozilla is mandating that issuance of certificates containing domains validated with the HTTP method be limited to issuance of exactly the validated domain. In other words, Wildcards and subdomain SANs will be prohibited for domains validated with the HTTP method.

This will impact customers since it’s a common method for performing domain validation and if you  want to continue using this method, then you must validate each SAN:DNSName individually.

Rotating ICAs at Shorter Intervals

Timeline: July 13, 2021 and then quarterly in 2022

GlobalSign will start rotating our Atlas TLS CAs on a scheduled basis to promote good ecosystem security and agility. Historically, we have set up CAs and used them for many years, but there are many reasons to reduce this time interval. By reducing the length of time CAs are used, we achieve the following benefits:

  • This limits the number of certificates issued by a single CA and its corresponding private key, which improves our own crypto-agility.
  • This limits the impact if there is an integrity, compliance or security issue with the CA.
  • This reduces the size of CRLs which increases validation performance.
  • This trains our customer base to expect and plan for immediate CA replacements which increases their crypto-agility.
  • Our final plan will have all GlobalSign Atlas TLS CAs rotated every quarter and all Customer dedicated Atlas TLS CAs rotated yearly.
  • The first GlobalSign Atlas TLS CA rotation for 2021 will take place on July 13, 2021.
  • Starting in 2022 we will update GlobalSign Atlas TLS CAs every quarter, on the second Monday of the quarter and we will update Customer dedicated Atlas TLS CAs yearly each January.

Impact and recommendations:

  • Customers should always be prepared to accept new CAs when installing new TLS certificates. The issuing CA is available in the API and should be used when downloading the certificate so that the current CA is always provisioned with the issued certificate.  
  • Customers MUST not do public key pinning to CA certificates, and we highly discourage public key pinning at all, as that defeats the purpose of crypto agility.
  • We encourage customers to follow agile practices for Issuing CAs and always download and install the provided ICA when obtaining new certificates.
  • Please subscribe to GlobalSign's Status page for important updates here - https://status.globalsign.com/

More information can be found on our Support website.

Changes to ECC Key Usage

Effective Date: July 26, 2021

We will be changing the key usages in our ECC TLS certificates to align with industry best practices and in-process changes to the CA/B Forum Baseline Requirements. Currently we include both digital signature and key agreement, but as of this date we will be changing this to include just digital signature.

Our public trust TLS is used by browsers and web servers to support TLS sessions for end user protection. We will always keep the security of the users of these certificates at the forefront in our considerations when creating new profiles or issuing CAs. It was decided that the need for Key Agreement in ECC certificate usage was no longer required within a TLS certificate, while also introducing potential security issues for end users because the signing key and encryption key should be separate keys within a TLS session. Due to these reasons, the extension was dropped from our general TLS offerings. Customers requiring custom profiles for tools and systems outside the confines of traditional browser-to-server TLS sessions should strongly consider private trust offerings.

Prohibiting Use of the OU Field

Timeline: TBD

Google has long been concerned with how the OU field in TLS certificates is being validated. The Baseline Requirements have clear requirements on all subject fields (C, S, L, Org, etc.) that require the data be obtained from a business repository; however, the OU field requirement remains as:

The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information.

This permits customers to supply unvalidated, and possibly misleading information which may be (inadvertently) relied upon.  As such, Google is strongly advocating the removal of the field.

This field is often used by organizations to help them manage the certificates by specifying the department to which the certificate belongs. Certificate reporting helps the organization allocate renewals and replacements based on this field; however, the purpose of the data in certificates is for relying parties, those that visit the site and want to make a decision as to whether or not they should trust the site and not for organizational certificate management.

Customers need to be aware of this upcoming change and to start planning on the deprecation of the OU field. While no date has been set, we will be phasing out the general use of the OU field in the coming months and collecting input for the root programs on why some continue to need the OU field.

Have questions? Visit our Support website for more information and ways to get in touch.

Share this Post