101
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 18 May 2025
101 points (98.1% liked)
Linux
7387 readers
59 users here now
A community for everything relating to the GNU/Linux operating system
Also check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
Im curious for Google's reasoning.
This honestly is basic security in a number of ways. Separate PKI for every use-case is the standard. Eggs in on ebasket, yadablahwut.
The actual change shouldn't take long for LE to actually do, it's the implication of the thing though. I'd love to see a different tool for enrolling TLS services, or at least a better flow than the existing one.
So what is the PKI for client certificate authentication?
How do you mean?
What is the public key infrastructure for obtaining client authentication certificates that have a path of trust back to a root CA? You said separate PKI for every use case, so what is the intended PKI for this use case, if not CAs like LetsEncrypt?
The PKI in this context is just the platform that is managing the issuing and revocation of certificates not the underlying algorithms being used, if that's what you're asking.
So the LE systems that accept, check, and approve the initial request, and then handle the revocation when needed. Using a different stack for different use-cases is a best practice, simply because if one is compromised, it doesn't affect the other. In this case it's just splitting the standard LE web services and TLD services into two different stacks that do the same thing, but I assume would have isolated CAs, one for each use-case. This would mean a new root CA needs to be deployed out into the world in order to verify the TLS side, but maybe I'm missing something.
Yes, FTA:
Yes, that's the same thing. Removing it from one place, and just adding it to another. No big deal.
I honestly don't think many people were even using this feature compared to SSL certs. Anyone using TLS everywhere already has their own cert manager workflow, othey'd be using another system to do it ala k8s, or they'd be doing it at the network fabric instead of per-service. I can't think of many use-cases where regular users of LE would have a TLS-enabled public service they would need other random users to trust. I'm sure there's some, but nowhere on the scale of their SSL users.
Adding it where?