Shorter certificates are coming!

Well, I was certainly hoping for this result, but wasn't necessarily expecting it! I'm pleased to report that Ballot SC-081v3 passed, and that shorter certificate lifetimes are now coming!

The Schedule

I will go into more detail later in the post, but right now, let's cover the important details! Here is the schedule that was proposed and voted on, and will now come into effect:

This means that the important dates are as follows:

March 15th 2026: All new certificates capped at 200 days validity

March 15th 2027: All new certificates capped at 100 days validity

March 15th 2029: All new certificates capped at 47 days validity!

It's a little sad that the dates slipped since the initial proposal of this ballot, hence the 'v3', but still, we now have a definitive date in the future when we know these things will be happening.

If we look at the progress of shortening certificates over time, we can see that the trend fits well, and if anything, our progress had stalled out a little, but we're now back on track, even if at a reduced pace.

You can see my views on the progress of this ballot in my earlier post, Are shorter certificates finally coming?!.

Who voted for what?

As the CA/B Forum votes are public, we can take a look at who voted for what, and in the past, that has given us some interesting insight into the sentiment across industry. If you want to view the official announcement, you can do that here, but here are the results.

The voting period for SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods has completed. The ballot has: PASSED

Voting Results

Certificate Issuers

30 votes in total:
 * 25 voting YES: Amazon, Asseco Data Systems SA (Certum), Buypass AS, Certigna (DHIMYOTIS), Certinomis, DigiCert, Disig, D-TRUST, eMudhra, Fastly, GlobalSign, GoDaddy, HARICA, iTrusChina, Izenpe, NAVER Cloud Trust Services, OISTE Foundation, Sectigo, SHECA, SSL.com, SwissSign, Telia Company, TrustAsia, VikingCloud, Visa
 * 0 voting NO:
 * 5 ABSTAIN: Entrust, IdenTrust, Japan Registry Services, SECOM Trust Systems, TWCA

Certificate Consumers

4 votes in total:
 * 4 voting YES: Apple, Google, Microsoft, Mozilla
 * 0 voting NO:
 * 0 ABSTAIN:

That is absolutely phenomenal support, and I think largely due to the open nature of the proposal, seeking to gather industry feedback and adapting the proposal based on that feedback. It's a little disappointing to see CAs abstain from voting, especially IdenTrust, but here are the responses from those CAs who abstained and provided a reason:

IdenTrust abstains from voting on Ballots SC-081v3.

While we agree with all proposals related to TLS DV validation and support full automation, we remain unconvinced of the security benefits of further reducing the validity period for OV and EV TLS certificates.

It's interesting that the opposition was not to reducing the validity of DV certificates, which can be easily automated, but to OV and EV certificates instead. It's widely known what my views on OV and EV certificates are ([1][2][3] etc...), but if we're assuming that those certificates have too much manual process involved, and thus require human intervention and are inherently unfriendly to automation, it's really just another nail in the coffin.

JPRS abstains from voting on Ballot SC-081.

We agree with the value of reducing certificate validity periods.
We also believe that this ballot indicates to subscribers the inevitability of automation and represents a significant step forward for the WebPKI ecosystem.

However, we will abstain from this ballot.
While we will do our best to support our subscribers and hope that subscribers and other stakeholders in the WebPKI ecosystem will be able to follow the proposed timeline, it is currently uncertain whether it can realistically be achieved.

In addition, we hope that discussions will take place even after this ballot when necessary, taking into account the actual state of migration in the WebPKI ecosystem.

It's good to see JPRS acknowledging the enormous benefit that this ballot brings, and I can also understand and appreciate the hesitation around the ecosystem being ready. Whilst adoption of automated solutions for certificate management has been going well, it's not been going well enough. With that said, there has also never been a requirement for people to adopt those solutions, it was simply a good idea to do so. Now that there is a requirement to have these solutions in place, and a generous 4 year window to get them in place, I'm hoping we start to see an increase in the rate of adoption and progress.

TWCA "ABSTAINS" from voting on ballot SC-081v3.

1. We agree that shortening the certificate validity period can reduce cybersecurity risks, and we also acknowledge the advantages of automated certificate management.

2. We believe that reducing the validity period from 100 days to 47 days is too drastic. Compared to the harm caused by phishing websites, there is currently no way to demonstrate to users how high the cybersecurity risk would be if the certificate validity period were 100 days.

3. For some websites that already use certificates, if they ultimately fail to deploy automated certificate management, they might abandon HTTPS in favor of HTTP (given that in today’s browser UIs, HTTP only displays a red warning in the upper left corner, whereas improper management leading to certificate expiration results in warnings across the entire page).

Again, it's great to see a CA acknowledge the value that these shorter certificates will bring, but after this, I start to struggle with this response. It's really not clear to me what point is being made in comment #2, but I'm not sure what relevance phishing websites have here, and I don't know what cybersecurity risk is present if a certificate is only valid for 100 days! For comment #3, I completely disagree. There's absolutely no reasonable concern that websites are going to move back to HTTP from HTTPS.

SECOM Trust Systems ABSTAINS from voting on Ballot SC-081v3.

We agree with the value of shortening certificate validity periods, and we support this direction in the long term.

In addition, we believe this ballot signals to subscribers that automation is inevitable, and that this is a great step forward for the WebPKI ecosystem.

On the other hand, we are also aware that some subscribers may experience costs to adapt.

In our business practice, we think it is important to be able to explain not only the value but also the cost and explain that our approach is net-positive for the web, unless there is a reasonable alternative.

Assuming a tradeoff between the period to prepare and the cost, we do not have an answer to shortening it to 47 days instead of 90 days.

Therefore, we abstain.

Lastly, SECOM are another CA acknowledging the enormous benefits that this proposal will bring, but I'm struggling to agree with their argument. It seems that they are suggesting that if certificates were valid for 90 days, then subscribers could/would renew them manually, but a validity period of 47 days would be too short for manual renewal to be practical. I'd make the argument that even at 90 days validity, manual renewal is completely impractical and should already be fully automated, so this doesn't make any real difference at all.

Come and geek out with me

If you really want to know more about this whole TLS/PKI ecosystem, why these changes are coming, and the years of history that are driving this, I'd really recommend you check out our training course:

There are full details of what we cover on the training page, but if you want to get hands on with TLS and PKI, fully deploy HTTPS to your own server, including getting a real certificate, build your own CA, and so much more, you should really get involved and join us! It's a fairly intermediate level course, I probably wouldn't recommend it for beginners, but it contains everything you're going to need from a practical perspective, and we have plenty of opportunity to talk about and understand current affairs too.