After careful consideration, Sectigo has decided to vote in favor of CA/Browser Forum (CABF) ballot SC22, which seeks to limit the allowed duration of TLS / SSL certificates to 397 days, or about thirteen months. It is a complex issue with pros and cons for both outcomes. This post will spell out our reasons for voting as we have.
The SSL industry has seen a general trend toward reduced certificate terms. Back in the 2000s it was possible to purchase an SSL certificate that was valid for as long as six or eight years. Over time CABF has whittled certificate lifespans down to the point where today the maximum term for an SSL cert is twenty-seven months. The last lifespan reduction occurred early in 2018, and should the current ballot pass, this next reduction will be April 2020.
The argument in favor of reducing certificate lifespans, boiled down, is that certificates inherently carry risk. There is always the possibility of a stolen key or the crafty abuse of a legitimately issued certificate. There is the chance, however rare, that a CA issues a certificate to the wrong entity by mistake. And as domain names can change ownership, it is possible to own a valid certificate for some period of time for a domain you no longer control.
All these risks are very small, and the vast majority of certificates are used honestly and legally for the full lifespan with no meaningful security concern. Nonetheless, all else being equal, shorter term certificates are less risky. Sectigo is one of the companies entrusted with stewardship of digital identity through issuing and maintaining certificates on public roots. We are the largest commercial public CA, and we take our responsibility very seriously. The opportunity to reduce risk for certificates is not one we take lightly.
The argument against reducing certificate terms is that it can increase administrative overhead for the certificate users, those who operate sites and servers depending on these certificates. The increased overhead may add time and hassle for certificate administrators, and it too can add risk of outage or other problems as the opportunity for error increases.
Recent news items such as 2018’s day-long data outage for O2, Softbank, and other mobile carriers (more than 32 million people left without service and an estimated SLA penalty of $100 million for Ericsson) and 2017’s Equifax data breach (entailing the theft of 45% of America’s PII and a $700 million fine for Equifax) show the potential consequences of unexpected TLS certificate expiration. The Equifax breach is especially illuminating in that the certificate expiration led to the failure of a system put in place to prevent exactly the kind of data exfiltration that drove this breach.
We don’t take these concerns lightly, either. As a public CA, we hold the responsibility for understanding how our customers use certificates and how changes in CABF rules will translate to real-world use cases. We have to be a voice for balance between overly strident security rules that stifle companies’ use of digital services and overly lax rules that introduce unacceptable levels of risk. Judging where on that spectrum to fall is nuanced and situational, and it depends on current and complete on-the-ground market knowledge.
In this case, one very important consideration was automation. In the past we and other CAs have sought the gradual reduction of certificate durations to minimize the risk of service interruptions. For the great majority of SSL’s more than two decades as a dominant computing paradigm, meaningful automation of certificate deployment, life cycle management, and renewal has been very rare. “Management by spreadsheet” has been the norm. Under that circumstance, reducing certificate terms from two years to one effectively doubles overhead and the risk of human error.
However, things are changing. The ACME (Automated Certificate Management Environment) automation protocol is proving hugely popular. With more that 150 million web sites using ACME and hundreds of tools providing support, ACME has the power to change the automation landscape. Plus, it’s not alone. SCEP (Simple Certificate Enrollment Protocol), EST (Enrollment over Secure Transport), and platforms like Sectigo Certificate Manager add to the list of options available to those seeking to automate certificate management.
For small businesses, they have increasingly moved to hosting providers or content delivery networks. The days of a server under a desk are for the most part behind us. These large, professional web hosting and delivery services are able to take advantage of the automation options listed above and remove that burden completely from the small business.
Certainly, automation is not ubiquitous yet. Watching many services and sites go offline over the course of the 2018/2019 US government shutdown was a clear illustration that we still have a way to go. Nonetheless, it is a trend that already has a great deal of momentum, and we expect that to continue and mature. We are doing our part through initiatives like our certificate management platforms (Sectigo Certificate Manager and IoT Manager) and our sponsorship of EFF’s Certbot certificate automation tool to extend its capabilities beyond just DV certs to OV and EV certs as well.
We expect the trend toward automation to continue. As SC22 (should it pass) will not go into effect until April 2020, it will be April 2021 at the earliest that this ballot will actually affect certificate administrators’ day to day operations. That gives them a year and a half to consider and implement automation solutions. We believe that should fit into any reasonable IT departmental roadmap, and we encourage enterprises and government agencies to begin working on their automation solutions today.