OpenSSL integration with UPKI
The recent eMudhra CA compromise highlighted a critical gap in Linux ecosystem security: while web browsers quickly revoked the affected intermediate certificates via proprietary revocation lists (like Mozilla’s OneCRL and Chrome’s CRLSets), Linux distributions were forced to manually respin and patch their core CA certificate bundles (ca-certificates) to drop the compromised intermediate and root certificates.
Static CA bundle updates do not scale during rapid security incidents. To solve this systemic issue, Linux distributions need a dynamic, platform-independent revocation infrastructure. UPKI (Universal Public Key Infrastructure), originally developed under the rustls umbrella, provides a browser-grade, offline-first revocation solution that fetches and caches CRLs/revocation metadata out-of-band (via a lightweight system daemon running an upki-fetch timer). The specification is available at https://c2sp.org/[email protected]
I’ve raised the discussion on this topic some time ago.
https://github.com/openssl/openssl/discussions/31932
Ubuntu has implemented the tech preview https://discourse.ubuntu.com/t/try-the-upki-preview-for-ubuntu/84705
Go is also going to implement support. https://github.com/golang/go/issues/82402
Nix has got a pull request: https://github.com/NixOS/nixpkgs/pull/578400
I ask the distro community to express their opinion on this topic. From my perspective integrating UPKI natively into OpenSSL 4.2 LTS would establish a universal, robust revocation layer for Linux environments without breaking existing application code contracts or requiring ad-hoc CA bundle respins during security crises. If supported, we still need to design the proper implementation.
Do you support integration of UPKI with OpenSSL?
poll by Dmitry Belyavsky Closing Mon 9 Nov 2026 8:00AM
Choose the option(s) you favor.
Current results
| Current results | Option | % of points | Voters | |||
|---|---|---|---|---|---|---|
| Yes, in 4.2 | 100 | 5 |    | |||
| Yes, after 4.2 | 0 | 0 | ||||
| No | 0 | 0 | ||||
| Not voted | 5 |     .jpeg){kind=small} |
Jaroslav ReznikMon 26 Oct 2026 8:53AM
Ideally 4.2 given the outcome of the recent eMudhra incident as it uncovered this to be a gap in the ecosystem and we can expect other CAs to become under more scrutiny now.
Gordon TetlowMon 26 Oct 2026 8:53AM
I like the "optional but default" opinion. I also believe a C implementation would be most useful.
Kurt RoeckxMon 26 Oct 2026 3:22PM
I have been wanting to have better PKI support for more than 10 years. This includes a trust store where you can define things like for what you trust a CA.
One of the functionalities that Mozilla has is being able to distrust certificates with a notBefore date, which probably isn't that important to have.
But being able to actually check the revocation status of a certificate is important. Any solution that improves it is welcome. If if can be used by multiple libraries that certainly a big plus.
I would like to see openssl do this by default. Applications should not need to be modified to get this functionality.
Rust is not a problem. For all arches Debian releases on, rust is available. It's only not available on old architectures.
Checking something like CT can be useful, but we would need to define some policy, have a list of logs that are acceptable and so on. I don't see that happening soon, nor am I sure we want to enforce that by default. Is that something UPKI also provides?
Clemens LangMon 26 Oct 2026 3:34PM
Rust is not a problem. For all arches Debian releases on, rust is available. It's only not available on old architectures.
I suspect there will be people working on OpenSSL who disagree with you on that — I personally agree, though. The people that don't have Rust will just not get working revocation checking.
Checking something like CT can be useful, but we would need to define some policy, have a list of logs that are acceptable and so on. I don't see that happening soon, nor am I sure we want to enforce that by default. Is that something UPKI also provides?
Yeah, that one is a bit trickier, so we shouldn't do it in the same push. On the other hand, browsers have this figured out already, so we could certainly steal learn from them. To my knowledge, UPKI does not provide CT checking (and I'm not convinced it would be in scope for the project).
At some point down the road, we'll also need a system service that regularly updates Merkle Tree CA landmarks, which happens to fit pretty nicely into a similar box as updating a CRL database — so having UPKI integration would also be good from that point of view.
Kurt RoeckxMon 26 Oct 2026 5:22PM
We will use the next LTS release, so I would like to see it in the next LTS release. Otherwise it's going to take an other 2 years before it hits our next release.
Clemens Lang ·Mon 26 Oct 2026 10:37AM
Yes, we should definitely look at having this. upki is Rust, so there will be older platforms left behind, but they're no worse off than they are today. I don't think older platforms should prevent us from improving security in more modern environments.
In other words: Yes, OpenSSL should support this, as an optional but default dependency.
The other thing that would have helped in this situation would be checking of certificate transparency SCTs, which I guess we should look into tackling as well.