Maximum SSL/TLS Certificate Validity is Now One Year

Starting on September 1, SSL/TLS certificates can not be issued for longer than 13 months (397 days). This change was first announced by Apple at the CA/Browser Forum Spring Face-to-Face event in Bratislava back in March.

Then, a couple of weeks ago, at the CA/B Forum’s Summer event (held virtually), Google announced its intention to match Apple’s changes with Google’s own root program.

There is also a browser-driven ballot that seeks to align the industry’s baseline requirements with the new root program changes. The CA/B Forum is currently debating this.

We realize there might be a lot to unpack here, so in the interest of providing a little clarity, we’re going to cover it in this article.

The reason for shorter SSL/TLS certificate lifespans

From a high-level, theoretical standpoint, there are two primary benefits for shorter-lived certificates:

The first is the technical component – longer lifespans means that it takes longer to roll out updates or changes organically. A real-world example would be the SHA1-to-SHA2 transition: Unless you’re going to revoke a whole bunch of certificates and force the customer to reissue, it can take years before all of the old certificates have been replaced. In the case of SHA1, it took three. That creates risk.

The other benefit has to do with identity: How long should information that is used to validate an identity stay trusted? The longer between validation, the higher the risk. Google has said that in an ideal world, domain validation would occur about every six hours.

Before 2015, you could get an SSL/TLS certificate issued for up to five years. That was reduced to three years, and then again in 2018 to two years. At the end of 2019, a ballot was proposed at the CA/B Forum that would have reduced it to one year – however; it was voted down soundly by the Certificate Authorities.

So, why are certificates still being reduced to one year?

The CA/Browser Forum is an industry group that meets to vote on a set of baseline requirements for the issuance of trusted digital certificates.

What the CA/Browser Forum is not, however, is a governing body. Therefore, even though the CAs expressed concerns and reluctance to decrease maximum validity again, Apple and Google are well within their right to update the policies for their root programs as they see fit.

We understand that we’ve just thrown a whole bunch of industry terms at you, so let’s step back really quick and make sure the previous paragraph makes sense:

Certificate Authorities and browsers have an interdependent relationship. Browsers need to use certificates to make trust determinations about websites and for help securing connections. From a CA’s point of view, what good is a public certificate if it’s not trusted by a browser?

The way this is all managed is through the root programs. There are four major root programs of note:

  • Microsoft
  • Apple
  • Mozilla
  • Google (the last two known as Googzilla – LOL)

Incidentally, you’ll notice those four are equivalent to the forces behind the major browsers on both desktop and mobile. For a CA to have its certificates trusted by the root programs and, by extension, the browsers and OSs that make use of them, the CA must adhere to that root program’s guidelines.

The CA/B Forum is an industry forum that ideally helps to facilitate changes to the root programs (and to the ecosystem itself). But the root programs, which participate as browsers, can still act unilaterally and make changes as they see fit.

When this happens, the need for interoperability basically dictates that whatever root program policy has the most stringent standards becomes the new de facto baseline requirement.

That’s how we got here. Now, let’s talk about what this means for your website and what you as a company can do to optimize your certificate management.

For a CA to have its certificates trusted by the root programs and, by extension, the browsers and OSs that make use of them, the CA must adhere to that root program’s guidelines.

What shorter SSL/TLS validity means for website owners

First things first: this change goes into effect on September 1, 2020. So, if you are using a two-year certificate that was issued before September 1, your certificate will stay valid until its original expiration date. You just won’t be able to renew it for two years moving forward.

Or, to put it another way: you have until September 1 to get two-year certificates. After that, they will be relegated to the desktop recycling bin of history. From a bigger-picture standpoint, this might be a good time to start considering automating more of your certificate lifecycle management:

Automated lifecycle management is especially crucial for larger organizations managing dozens of publicly-trusted website certificates, but also for organizations using publicly-trusted email certificates and any organization leveraging private CA or PKI-based electronic signatures.

The way things are headed with the root programs continuing to push for shorter validity, organizations will pretty much be forced to automate a lot of these things at some point in the future. Better to explore this now than when your feet are held to the fire.

How TRUSTZONE will handle one-year certificates

In the interest of making the process as straightforward as possible, starting on August 31, TRUSTZONE will provide SSL/TLS customers with the maximum validity of 397 days when ordering one-year certificates. This new standard applies to new certificate orders as well as certificate renewals. This way, we can provide you with the maximum possible validity for your benefit.

You will still want to renew your certificate before it expires. Also, since we can no longer provide up to 90 additional days to your validity, we recommend that you renew your certificate within 30 days of expiration.

What about reissuing my certificates?

You may wonder what happens when you reissue one of your two-year certificates after this change goes into effect. Well, we have good news for you!

If you reissue a certificate and lose validity (we’re required to limit validity to 397 days), you can reissue the certificate later ideally less than 397 days before your original certificate expires and recover the lost validity from your first reissue. This works the same way it did in 2018 when we went from three-year maximum validity down to two years.

One thing worth noting is that the EV reissue process is a bit different due to the EV Guidelines (EVGL) requirements for reissuing certificates.  While you can still reissue your certificates, they will be queued for manual review, and we will need to make sure that all validations are up-to-date before we can release them.

If you have any questions about how these changes may uniquely affect your organization or website, please don’t hesitate to contact us – just fill out the contact form below: