OpenSSL Communities

Better revocation in TLS

Clemens Lang Wed 28 Oct 2026 10:21AMPublicSeen by 19

I hope by now everybody has more or less recovered from last week's d=4 private key debacle… so now I'm wondering — is there consensus in the large business community that we should do something about this so the next time isn't as bad? Do you have working revocation in your products, or is that a gap for you?

There are a few avenues to explore from OpenSSL's perspective:

UPKI

UPKI is a rust-based daemon that keeps a copy of a CRLite database (what Firefox uses) up to date and offers current certificate revocation information either using a C API or by directly accessing its database. Go, Ubuntu and Nix are planning to support this, and @Dmitry Belyavsky has opened a discussion for OpenSSL.

Since this is a long-running daemon process, it's probably something we should all rely on to get from the underlying operating system rather than packaging it separately with various products, just to prevent multiple copies running on the same machine. For that to work reliably, distributions need to agree to provide the same API though (i.e., a single easily-findable place for either the database or the loadable module with the C API, or both) — otherwise we end up in the mess of paths for the trust database that exists today across distributions.

Does the large business community have opinions and/or concerns about this? Would you like to see this implemented, and if so, when?

I have also heard a rumor that the upstream project wouldn't mind some additional funding — so if you're looking for a place to put your money in response to a post-mortem: *hint, hint*.

Certificate Transparency

One other approach that would have limited the impact of the eMudhra incident would be checking of Signed Certificate Timestamps from Certificate Transparency logs and requiring their presence — certificate transparency logs were quick to block accepting new pre-certificates from the affected intermediates. Browsers such as Chrome or Safari enforce the presence of SCTs in certificates, but OpenSSL does not.

On the other hand, checking SCTs requires additional configuration and trust decisions, such as:

  • for which CAs are SCTs required (can't require them by default for private CAs, unless those also run a transparency log)

  • which logs do you trust, and where and how do you configure their public keys

  • how many logs must witness a certificate

OpenSSL has support for certificate transparency checking, but at the moment it needs to enabled explicitly by an application, and OpenSSL ships with an empty ct_log_list.cnf file by default.

Does anybody in the large business community actually use OpenSSL's certificate transparency functionality? Should it be enabled by default, and if so, with which configuration?

Note that UPKI includes "certificate transparency enforcement" in its stated "later goals", so maybe going for that first is the correct choice anyway and will eventually give us better support for CT as well?

Which solution should OpenSSL prioritize?

dot vote by Clemens Lang Closing Thu 5 Nov 2026 3:00PM

Resources are always finite. Where do you see the best return on investment, and what should OpenSSL's longer-term strategy be?

In this poll you have a budget of points to allocate to the options you prefer. You can allocate all points on one option or spread them out.

Current results

Dmitry BelyavskyWed 28 Oct 2026 10:29AM

3 - Add UPKI support to OpenSSL upstream
0 - Enable CT support by default
0 - None of the above

UPKI provides more or less universal solution and can be extended to deal with custom data, e.g. private CAs. Certificate transparency doesn't carry revocation information which is more important in case of immediate revocation

Watson LaddWed 28 Oct 2026 6:25PM

We have working revocation in code we write. But the broader ecosystem does not, and we depend on it. UPKI integration across all tools is vital to ensure security, and that means distros and downstream packagers need a solution that works for them.

CT logs as enforcement for webPKI does not solve all cases where revocation is the answer.

Dmitry BelyavskyWed 28 Oct 2026 7:42PM

@Watson Ladd does Akamai also fits distribution requirements? If yes, could you please vote also there?

Watson LaddThu 29 Oct 2026 5:34PM

@Dmitry Belyavsky Nope, We're just customers of distributions.

Alicja KarioThu 29 Oct 2026 2:14PM

The big issue is that trust stores like Mozilla make decisions with the assumption that all the information in them, and the additional mechanisms (CT, policies, CRLite) are used together with it.

So to provide the same level of security as Firefox or Chrome provide to the users we need to perform the same compliance and revocation checks as those browsers do.