Addressing Linux's missing PKI infrastructure

[Posted December 8, 2025 by jzb]

Jon Seager, VP of engineering for Canonical, has announced a plan to develop a universal Public Key Infrastructure tool called upki:

Earlier this year, LWN featured an excellent article titled "Linux's missing CRL infrastructure". The article highlighted a number of key issues surrounding traditional Public Key Infrastructure (PKI), but critically noted how even the available measures are effectively ignored by the majority of system-level software on Linux.

One of the motivators for the discussion is that the Online Certificate Status Protocol (OCSP) will cease to be supported by Let's Encrypt. The remaining alternative is to use Certificate Revocation Lists (CRLs), yet there is little or no support for managing (or even querying) these lists in most Linux system utilities.

To solve this, I'm happy to share that in partnership with rustls maintainers Dirkjan Ochtman and Joe Birr-Pixton, we're starting the development of upki: a universal PKI tool. This project initially aims to close the revocation gap through the combination of a new system utility and eventual library support for common TLS/SSL libraries such as OpenSSL, GnuTLS and rustls.

No code is available as of yet, but the announcement indicates that upki will be available as an opt-in preview for Ubuntu 26.04 LTS. Thanks to Dirjan Ochtman for the tip.

to post comments

Already Obsolete?

Posted Dec 8, 2025 18:13 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (6 responses)

Isn't the CA/B's plan to obsolete CRLs kind of making this project itself obsolete? The long-term goal is 7 day certificates IIUC (45-day coming in the next year or two). At that point, the certificate is expired by the time "everyone" would have gotten around to doing CRL-based distrusting. But we know that 7-day expiration is a ways away, so maybe this has a useful window at least.

Already Obsolete?

Posted Dec 8, 2025 18:48 UTC (Mon) by grawity (subscriber, #80596) [Link]

CA/B's rules apply only to public "web PKI" certificates, which are specifically those 1) with the "TLS server" usage and 2) issued by one of the browser-trusted CAs (the /B in CA/B).

But there are plenty of PKIs beyond the web (e.g. IGTF Grid PKI (which has its rolled its own 'fetch-crl' tools), or EU's Qualified Signing PKI, or DoD's massive internal PKI, or various other mostly-AD-CS-based corporate PKIs) – and of course there are other certificate types beyond TLS server (e.g. "TLS client" certificates, or "S/MIME" email certificates, or Authenticode .exe signing certificates, or document signing certificates).

(For example, the qualified signing certificate in my ID card is issued for 5 years, with CRLs and OCSP (and no ACME – I get to physically walk into an office to renew it). The officially-accepted signed-document formats bundle an OCSP response to show that it wasn't revoked at time of signing.)

All of those are not subject to CA/B's rules – and often not subject to "web PKI" limitations (like the avoidance of massive CRLs).

Already Obsolete?

Posted Dec 8, 2025 19:17 UTC (Mon) by brunowolff (guest, #71160) [Link] (1 responses)

Also they are a privacy issue as well. (I believe that stapling was meant to address this.) The privacy issue exists as longs as you are looking up revocations per cert (as opposed to regularly pulling down complete lists from each CA). Revoked certs being used for attacks is a very rare occurrance. So I expect for a lot of people not using CRLs is a better choice.

Already Obsolete?

Posted Dec 9, 2025 13:28 UTC (Tue) by iabervon (subscriber, #722) [Link]

CRLs are the complete lists from each CA. It's non-stapling OCSP that's the privacy issue, not CRLs, which are the complete lists per CA, not revocations per cert.

Already Obsolete?

Posted Dec 8, 2025 23:06 UTC (Mon) by muase (subscriber, #178466) [Link] (2 responses)

I guess we will see if that really happens soon™. First of all, that requires significant investments in infrastructure – currently, even Let's Encrypt is barely holding up with their current load, with requests failing repeatedly on their side.

A 7-day expiration for everyone is going to put a lot of additional pressure on the CA infrastructure here, and also is an availability risk. We are seeing an increased amount of larger outages from the big players like Cloudflare; and with 7 days, even a smaller outage of Let's Encrypt would have a significant impact suddenly.

Also, I think we can expect significant resistance from big players like banking or other regulated industries, and probably not without reason – at least from their perspective. An automated component that pulls certificates from some source, and has the permissions to deploy them automagically on critical infrastructure like this, is a compliance challenge. Playing Advocatus Diaboli here, I see their point – shorter lifetimes are a good idea; but lifetimes that basically force you to automate sensitive processes – and make the human control loop basically impossible – might be a bit too much.

So, long story short: could be that we will really get 7-day certificates in the foreseeable future; but even for browser-based certificates I wouldn't bet on it. I think something like 90 or 30 days are more realistic, but then again that's long enough for CRLs to make sense again.

Already Obsolete?

Posted Dec 9, 2025 11:04 UTC (Tue) by kleptog (subscriber, #1183) [Link] (1 responses)

At some point you have to wonder if it's all worth the pain. The idea here (I believe) is that you want to handle the situation where a private key/certificate is leaked and you want to limit the time it can be used to impersonate that site.

But to be able to use this you also need to MITM the connections from the clients, which is difficult to pull off unnoticed at scale. So we're talking about small targeted attacks. But if it's a targeted attack, in a position to MITM someone reliably they're probably state actor anyway, and they can just send a National Security Letter to Cloudflare to ask them to handover the private key/certificate.

How often does this happen? I think cycling every 30-60 days a reasonable goal, but more often than that just seems overkill.

https://xkcd.com/538/ comes to mind.

Already Obsolete?

Posted Dec 10, 2025 14:49 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

> But to be able to use this you also need to MITM the connections from the clients, which is difficult to pull off unnoticed at scale. So we're talking about small targeted attacks.

Or nation-state actors. China pervasively MitM's all connections all the time, and does not care if you "notice" them doing so.

> But if it's a targeted attack, in a position to MITM someone reliably they're probably state actor anyway, and they can just send a National Security Letter to Cloudflare to ask them to handover the private key/certificate.

The US can do that. China (probably) cannot. Or they can, but then Cloudflare will say "no," and China will either block half the western internet or not.

Why not DNS?

Posted Dec 13, 2025 8:54 UTC (Sat) by zhangyoufu (guest, #130828) [Link] (1 responses)

Personally, I don't like the idea of running another daemon to solve the WebPKI revocation problem. It immediately comes to my mind that why don't we distribute certificate revocation status via DNS (DNSSEC).

Reliable and Decentralized Certificate Revocation via DNS: The Case for RevDNS
Protick Bhowmick, Dave Levin, and Taejoong Chung
In Proceedings of the ACM SIGCOMM (SIGCOMM'25), Coimbra, Portugal, September 2025

PDF: https://taejoong.github.io/files/publications/bhowmick-20...
Talk: https://www.youtube.com/watch?v=hXASMw1JL8M

Why not DNS?

Posted Dec 13, 2025 9:04 UTC (Sat) by zhangyoufu (guest, #130828) [Link]

There're many more research and effort in this area. Although none of them were adopted.

The DNS-Based scheme to revoke certificates in Transport Layer Security (TLS) Protocol: TLSR
https://datatracker.ietf.org/doc/draft-jilongwang-dnsop-t...

OCSP over DNS (ODIN)
https://datatracker.ietf.org/doc/draft-pala-odin/