Starting on September 1st 2020, SSL/TLS certificates cannot 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 last week, at the CA/B Forum’s Summer event (held virtually), Google announced its intention to match
Apple’s changes with its 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. That issue is currently being debated by the Forum.
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 blog post.
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 it takes longer to organically roll out updates or
changes. 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 re-issue, it can take years before all of the old certificates are
replaced. In the case of SHA1, it took three. That creates risk.
The other benefit has to do with identity – how long should the information used to validate an identity stay
trusted? The longer between validation, the greater 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, and
then again in 2018 to two. At the end of 2019, a ballot was proposed at the CA/B Forum that would have
reduced it to one year – it was voted down soundly by the Certificate Authorities.
What shorter SSL/TLS validity means for website owners
First things first, this goes into effect September 1, 2020. So, if you’re 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 for two years moving forward.
Or to put it another way, you have until the first of September to get two-year certs. 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 giving consideration to automating more
of your certificate lifecycle management functions. Especially for larger organizations managing dozens of
publicly-trusted website certificates, but also for organizations using publicly-trusted email certificates, as
well as any organization leveraging a private CA or PKI-based electronic signatures. You might also consider
moving some certificates from public to private trust, which also helps with management – you could even
issue certs with longer validity using that method.
Otherwise, the way things are headed with the root programs continuing to push for shorter validity – organizations
are pretty much going to be forced to automate a lot of these things at some point in the future.
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 prior to your original cert expire – and recover the lost
validity from your first reissue! This works the same way it did in 2018 when we went from three-year max validity
down to two years.
One item to note 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’ll need
to be sure all validations are up to date before we can release it.
If you have any questions about how these changes, please don’t hesitate to Contact US.
Nexus Technologies
UAN: 0300-0341140
