Earlier this year, Apple announced that it would limit the lifetime of trusted certificates to 398 days. Shortly after, both Firefox and Chrome followed in their footsteps.
Why limit the certificate lifetime? #
The goal is to create a more secure web environment. By reducing the certificate lifetime to a maximum of 398 days, or roughly 1 year and a month, it forces administrators to rotate certificates more frequently.
By doing so, the private & public keys get changed. Anyone that managed to compromise the private key will only see it be useful for, at most, a year.
What does this mean? #
Any new certificate that is issued after September 1st, 2020 will at most be valid for a year (*).
Some vendors still allow you to purchase multi-year certificates. How does that work then? Well, you'll get a discount for the multi-year purchase, and every year they'll send you a new certificate to replace the previous one.
At that point, you take counter-party risk as you're betting on the company still existing in 3 years to provide the certificates you already paid for.
This only applies to publicly trusted certificates. If you've deployed your own internal CA, those certificate lifetimes may still exceed 398 days.
What's going on behind the scenes? #
The story is actually quite fascinating!
Last year, members at Google initiated a ballot to reduce the maximum certificate lifetime to 1yr. The ballot is done via the CA/B Forum, the industry standard way that groups SSL issuers, browsers, important stakeholders, etc.
The ballot failed. The industry failed to come to a consensus and thus, no new rules were created to limit certificate lifetime.
Now this is where it gets interesting. Votes are split between certificate issuers and consumers. The issuers, or the ones where you buy your certificates from, voted mostly against the proposal.
The consumers of the certificates, or the browsers, all voted for the proposal.
Quite an imbalance there, isn't it?
A few months later, Apple announced it would limit certificate lifetime in Safari. One browser started to adhere to more strict certificate validation rules on its own.
Even though no consensus could be reached through the CA/B Forum, because the browser that hold 80%+ of the market share agreed to limit the certificate lifetime, the issuers of certificates have no choice but to follow along.
What do we feel about this? #
We applaud this move in general because it does a few things very well:
- It forces more rapid recycling of public certificates
- It promotes automation, to reduce the burden
- It will ultimately lead to bigger adoption of Let's Encrypt. If you're going to automate your certificate renewal, why not use free ones at the same time?
At the same time, it also shows the imbalance of a public forum like CA/B.
This move is generally positive, but if a major browser would unilaterally decide to implement a negative change to certificate management instead, is everyone else forced to adopt that too?
It's food for thought, for sure.
Increased need for certificate monitoring #
Of course, with the max lifetime of certificates decreased, you'll be having to replace your certificates more often.
Oh Dear can give you peace of mind with extended certificate monitoring. We'll keep you informed on the expiration days.
Because we now need to check for both expiration and validity times, we added additional checks that will inform you if you have a certificate that exceeds the 398 days threshold.
On top of that, we can let you know once your certificates change.
Imagine you're replacing a certificate, but are you 100% certain you've included all the same domains/SANs and it covers all the right hostnames? We've got you covered.
Don't let an expired certificate ruin your day. Monitor it with Oh Dear.