An industry group of web browser makers and certificate authorities is considering a proposal to limit the lifespan of digital certificate certificates to just a little more than a year.
Google engineer Ryan Sleevi, submitted the proposal to the CA/Browser Forum, an industry group of certificate authorities, major browser makers, and software developers. The CAB Forum sets standards and policies over how security certificates are issued and used on the web, and how long a TLS (Transport Layer Security) certificate should be valid is a recurring topic. Sleevi’s proposal would shorten the maximum validity period to 13 months from the current 27 months. There’s nothing to stop CAs from issuing certificates with shorter validity periods—the idea is that certificates have to expire after a certain time.
TLS certificates are used to encrypt connections to websites and to ensure that someone else cannot tamper with the user sessions or eavesdrop on communications being sent to and from the site. The browser can tell a certificate is valid and can be trusted up until the expiration date—after that date, the browser will stop sending users to that site because it doesn’t know if the site can be trusted. It is the website owner’s responsibility to renew the certificates to ensure that users can keep getting to the site.
The latest proposal would shorten the validity period to 13 months from the current 27 months. It used to be eight years, before it was shortened to five years, and then three years. The forum voted to set the maximum validity period to 27 months in 2017, as a compromise decision because certificate authorities balked at a different proposal to slash the validity period from 39 months to 13 months. Sleevi tried to get a vote on 13 months earlier in the year but did not get traction then.
If the proposal gets enough votes, the measure will take effect March 2020.
In an ideal scenario, websites will always have certificates using the latest cryptography, and one way to ensure that is by making websites renew the certificates frequently. Short validity periods ensures that older, insecure algorithms aren’t hanging around the ecosystem for a long time. If a certificate gets stolen, that’s fine, too, since they would expire shortly. The downside of shorter validity periods is that websites have to renew certificates frequently.
From a security standpoint, this proposal makes a lot of sense, and is one of the reasons browser makers Google and Mozilla support shortening the lifespan of these certificates. If there is a policy change or cryptographic standards change, the browser makers don’t want to have to wait more than a year for all the existing certificates to expire. For example, if this change goes into effect March 1, 2020, browsers still have to trust certificates that were issued in February and January for the full two-year period. If the decision is made to switch to a stronger cryptographic algorithm than SHA-2 (SHA-256) in certificates (which will happen some day), browsers will have to wait more than two years under the current scheme for all the already issued certificates to expire. That is a long time for certificates using deprecated methods to be still trusted.
The “validity period of certificates represents the single greatest impediment towards improving the security of the Web PKI,” Sleevi has said in the past.
Digicert’s Timothy Hollebeek opposes the proposal, arguing the security benefits aren’t enough to offset the increased headaches for website owners who have to renew more often. "Rapidly reducing certificate lifetimes to one year, or even less, has significant costs to many companies which rely on digital certificates to protect their systems."
That argument makes sense on the surface, except free certificate authority Let's Encrypt issues 90-day certificates. Let's Encrypt currently has more than 100 million active certificates, and it is growing every day. If website owners can keep up with Let's Encrypt's short timespans, then they can keep up with 13-months from other CAs. Keeping up with frequent renewals is difficult if the organization is handling the process manually. Let's Encrypt customers don't have a problem with shorter validity periods because the CA provides an automated process that handles renewals. Most CAs don't, and most organizations have not automated their certificate management processes, either.
It sounds trite to keep insisting that security needs to be automated, but this is one of the situations where it really does. Organizations that have tens of thousands of certificates deployed across their network and websites (and more they may have missed or don't know about) spend weeks coordinating with different teams to get certificates renewerd and redeployed. CAs aren't wrong in arguing that many organizations aren't currently equipped to handle a rapid cycle of renewals.
“Certificate management continues to be a manual process for most businesses – a shortened lifespan means IT teams will have to invest 3X to manage rolling certificates, which produces a 3X outage and configuration misstep risk," said Keyfactor’s chief security officer Chris Hickman. "Our research shows that 71 percent of businesses don't even know how many certificates they have – leaving them ill-equipped to revoke and reissue at scale.”
But the answer shouldn't be keeping the validity period the same. Instead, the industry--browser makers, CAs, and developers--should be figuring out a way to make the process easier for website owners. Let's Encrypt is getting a lot of traction because it has software that handles renewals--tools that take away the manual effort will go a long way towards fixing this problem.
A shorter maximum lifetime makes it possible for browsers and organizations to adapt faster to changes in security. For individual end users, this policy doesn’t really matter. For website owners, this can be challenging, especially if they aren’t using Let’s Encrypt’s automated system. But from the perspective of the ecosystem, it impacts how quickly algorithms can be changed, or mistakes be rectified.