CRLite is awesome, and it deserves more usage; notably most non-browser clients on Linux machines don’t get any revocation handling at all.

I remember you talking about this the other day when we met at RustWeek.

The CLI tools on Linux have certainly missed many of the recent great improvements in verification technology, so there is a gap between browsers and non browser components doing TLS now. OpenSSL doesn't enable CT by default, unlike Chrome, and it also doesn't handle revocations well either, nor does it enforce the certificate lifetime requirements.

The best solution would be a very stable IPC based API which connects to a systemd service (or something deployed as widely as systemd).

That component could probably also manage the certificates, and only apply these restrictions to "global" certificates. It could distinguish manually configured ones from explicitly configured ones. IIRC most of the file based standards the linux distros adopt can't even distinguish that.

That service would then do the locking needed to have on disk state (CRLite).

It's a complicated project, but also not on the scale of hundreds of thousands of lines of code: most of the components and libraries are available already. One needs to glue it together in the right way and then package it up nicely.

The complicated part would be to convince the Linux community to adopt it hahah.