All server certificates will be limited to under 398 days before 1 September.

The short version

From 1 September 2020, only SSL/TLS server certificates under 398 days can be issued, i.e. approximately 1 year and 1 month.

Existing certificates issued up to and including 31 August 2020 can technically be up to 825 days, i.e. approximately 2 years and 3 months.

As long as the certificate was issued no later than August 2020, it can be up to 825 days. If you want to extend certificates today that perhaps have more than 90 days remaining, this may also be possible with most issuers. Please contact us.

If a certificate must be reissued after 31 August 2020 and it has more than 397 days remaining, it will be reduced to 397 days upon reissuance. It will normally be possible to reissue the certificate free of charge in multiple rounds and thereby obtain the full time that was originally purchased.

This does not affect "internal" certificates issued from an internal CA that have been added to the computer by the user or administrator in trusted issuers.

Our recommendation

If a certificate can be renewed before September 2020 and there is no significant likelihood that the certificate's SAN names will need to change later or that the certificate will need to be reissued, we recommend renewing for 2 years no later than August 2020.

After that, certificates will simply be issued for 1 year at a time.

We are happy to help review options for organisations that want to automate certificates via the ACME protocol, via API, via Azure Key Vault, or have other automation needs.

There is also the option of "automatic renewal" or purchasing certificates for multiple years at a time, but this does not change the fact that the certificate still needs to be installed each time. Please contact us if you would like to use these services.

When specific certificates are limited

Code Signing and email certificates are not affected and can still be purchased for up to 3 years.

Certificates issued from your own private CA, e.g. internally within the organisation, are not affected.

Certificates from the following brands are reduced to 397 days after 18 August 2020

  • Sectigo
  • Comodo (now Sectigo)

Certificates from the following brands are reduced to 397 days after 27 August 2020

  • DigiCert
  • Thawte
  • GeoTrust
  • RapidSSL

Certificates from the following brands are reduced to 397 days after 30 August 2020

  • GlobalSign
  • AlphaSSL

Who is demanding shorter lifetimes

It is Apple, Google Chrome, and Mozilla who are behind this change.

The browsers, with Google Chrome leading the way, are together forcefully pushing this change upon CAs and certificate users. And this time, the change was for the first time not approved in the CAB Forum via a vote. Instead, the browsers simply announced that they are implementing code that rejects certificates issued from 1 September with a total lifetime over 398 days. And that CAs who disagree may be removed from the browsers' trusted CA root certificates.

What is supposed to become more secure

Where it will clearly help is when security vulnerabilities are discovered or specific security changes are needed for certificates, such as the deprecation of MD5 and SHA1. Less time will pass before all certificates created with the "old" deprecated/changed settings expire and are thereby replaced with newer, more secure settings.

The idea is that by making it more cumbersome to maintain certificates manually, due to the shorter lifetime, more organisations are forced to use automated installation methods. However, this will require updates to a great deal of software before it can happen. It also appears that Google Chrome wants to get down to a few months and is not done pushing to reduce the time further.

However, this does not help organisations that have not fully automated their server operations and maintenance, as one might imagine Google themselves have. Microsoft was told to replace 6+ million certificates in July 2020 and their answer was that it would take 7 months, so they probably do not have the kind of automation Google dreams of either.

Reducing the lifetime also does not help with errors that are considered rule violations, where Chrome and other browsers demand that all certificates regardless of number (e.g. 6+ million certificates at Microsoft) must be revocable within 7 days of the error being discovered.

There is an argument that a compromised certificate can be misused for a shorter time, as it is valid for 1 year rather than 2 years. However, this seems like a weak argument, since a misuse for most organisations would be catastrophic even within 24 hours, but it can "only" be misused for about a year. Most cases where certificates have been misused show that they were typically used for less than 2 weeks. The argument only becomes relevant when the lifetime gets below one month.

Furthermore, keys for certificates are often reused, which produces the same result as if the certificate were valid for several years. There are no restrictions on key reuse. There is not even an effective overall restriction on reuse of known compromised keys.