A decision that Apple unilaterally took in February 2020 has reverberated across the browser landscape and has effectively strong-armed the Certificate Authority industry into bitterly accepting a new default lifespan of 398 days for TLS certificates.
Following Apple’s initial announcement, Mozilla and Google have stated similar intentions to implement the same rule in their browsers.
Starting with September 1, 2020, browsers and devices from Apple, Google, and Mozilla will show errors for new TLS certificates that have a lifespan greater than 398 days.
The CA/B Forum and the TLS lifespan
The move is an important one because it not only changes how a core part of the internet works — TLS certificates — but also because it breaks away from normal industry practices and the cooperation between browsers and CAs.
Known as the CA/B Forum, this is an informal group made up of Certificate Authorities (CAs), the companies that issue TLS certificates used to support HTTPS traffic, and browser makers.
Since 2005, this group has been making the rules on how TLS certificates should be issued and how browsers are supposed to manage and validate them.
Browsers and CAs usually discussed upcoming rules until they reached a common ground, and then they passed rules that all members implemented.
However, across its 15-year history, there’s been one topic that has always ruffled the feathers every time it has been brought up — and that’s the lifespan of TLS certificates.
TLS lifespans started at eight years, and through the years, browser makers have chipped away at it, bringing it down to five, then to three, and then to two.
The previous change occurred in March 2018, when browser makers tried to reduce SSL certificate lifespans from three years to one but compromised for two years after an aggressive pushback from CAs.
But barely a year passed since they cut the TLS lifespan from three to two years, and browser makers tried again, to the dismay of CAs, who, at that point, thought they reached a compromise and put the matter to bed.
As ZDNet reported last summer, browser vendors tried again to bring the lifespan of TLS certificates from two to one year. The vote on this proposal, called by Google, failed in September 2019. While the proposal gained 100% support from browser makers, only 35% of CAs voted to approve a one-year TLS certificate lifespan.
Browser vendors overrule the CA/B Forum
But in February, Apple broke standard CA/B Forum operating procedure. Instead of calling for a vote, Apple simply announced its decision to implement 398-day lifespans on its devices, regardless of what the CAs in the CA/B Forum thought of the issue.
Two weeks later, Mozilla announced the same, and earlier this month, Google also followed through with a similar announcement.
Chrome joins Apple in limiting public TLS certificates to 398 days starting Sept 1st.
— Dean Coclin (@chosensecurity) June 10, 2020
What took place this year is, in no simpler words, a demonstration that browser makers control the CA/B Forum, and that they hold full control of the HTTPS ecosystem, and that CAs are merely participants with no actual power.
What happened this year was also predicted by HashedOut, a CA-friendly news site dedicated to the CA industry.
“If the CAs vote this measure down [the September 2019 ballot], there’s a chance the browsers could act unilaterally and just force the change anyway,” the site wrote in August 2019, a month before the vote.
“That’s not without precedent, but it’s also never happened on an issue that is traditionally as collegial as this,” it added. “If it does, it becomes fair to ask what the point of the CA/B Forum even is. Because at that point the browsers would basically be ruling by decree and the entire exercise would just be a farce.”
Why browser vendors cared so much about shorter TLS certs
To outsiders, all of this looks like some silly drama over technicalities and a play for power. However, there is a reason why browser makers have been pushing hard for shorter TLS certificates.
The primary reason is that bad TLS certificates get cycled out faster.
The norm is that once a TLS certificate has been abused for malware, phishing, or other operations, the certificate should be revoked by CAs.
However, in practice, the certificate revocation process has been a mess for years, with very few CAs revoking certificates in time, and bad certificates remaining valid for years, allowing bad guys to use and re-use the same cert for multiple operations.
Browser makers argued that by reducing the TLS certificate lifespan, these certificates would become invalid faster, even if they were issued by slacking CAs.
Furthermore, there is also the issue of traffic decryption. At one point in the future, browser makers anticipate that threat actors will be able to decrypt the HTTPS traffic they are logging today.
By securing traffic with shorter-lasting certificates, browser makers hope to make this process more resource-intensive for attackers.
CAs have been fighting against shorter lifespans because they believe none of these issues actually make a difference, as malware operations tend to abandon TLS certificates after they used them once, especially now since many companies provide free TLS certificates under various offers and programs.
Shorter lifespans just create more work for their IT teams and change industry standards that they believe should remain unchanged — as this is how standards are supposed to work, by remaining the same, not by getting updated every year.
Nonetheless, the issue has been decided, and CAs are nowhere near satisfied as to how the entire process played out. In a May 2020 meeting of the CA/B Forum, some CAs provided public responses to Apple’s decision, and many didn’t have a positive tone.
Actalis said that “like it or not” they “are forced to comply.”
D-TRUST, another CA, said that it, too, was forced to comply with this new TLS lifespan, but they made it clear they didn’t see “any security gain or other benefits by shortening the certificate lifetime.”
Telia described the whole thing as “an unnecessary burden to our community.”
And the replies go on, in the same passive-aggressive tone of “yeah, we’ll do it, but we’re not happy about it.”
What this means after September 1, 2020?
For certificate authorities: If they want the TLS certificates they issue after this date to be recognized in Apple, Google, and Mozilla browsers, the certificates must not have a lifespan that exceeds 398 days or the certificate will issue an error and connections will be dropped.
For website owners: They’ll have to renew TLS certificates yearly, instead of two years.
For end-users: They might see more HTTPS errors in their browsers.
