How about you join the uproar currently building and help us fight Google on this new policy that, I’m sure only accidentally, breaks quite some use cases, especially in tiny, self-hosting, federating installations?
(Apologies, having trouble with Discourse; fat-fingered a delete and now am not allowed to post a message that's too similar to something that I posted recently. This prefix added to workaround that limitation. (sigh) )
Is there an uproar? I stumbled across XMPP's lack of client authentication requirements when I was looking specifically for discussion in the XMPP community about the affects of this change, and couldn't find any. Pointers would be appreciated.
Are you aware any "tiny, self-hosting, federating installations" for other protocols that are affected by this change? Again, pointers would be appreciated.
1 Like
But what about 100 men in the browser space
2 Likes
FWIW, the discussion is taking place on mailop.org mailing list as well:
[mailop] No more TLS client certificates from public CAs
And the consensus there also is that this won't – or at least shouldn't – have an impact on public SMTP (ie. without prior private agreement between communicating parties).
10 Likes
Are they affected?
1 Like
Every times when WebPKI or certificates policies changed, we get some people yelling, some of them are just don't like change, but lots of them are relying one of the changed policies that are not the intended usage, like "I'm getting troubles on my always offline systems" or "My IoT devices...." when 47 day policy comes, this is why you need to generate your on root CA.
Sounds like some mail servers are relying wrong function to check the origin, the correct way is SPF+DKIM+DMARC
People are previously arguing reverse DNS lookup is important for mail servers, but since DKIM become supposed on most mail servers, this problems are gone, not to mention reverse DNS still not an option for lots of providers.
5 Likes
I would very much like for it to continue to be possible to get client certificates from LE, even if it's optional and by default LE issues server-only certificates.
If LE is committed to not even providing the option of client certificates, is anyone aware of a reasonable alternative source for client certificates, for those of us who have been relying on letsencrypt for them and will be left out when this change is made?
Technically this states What services does Let’s Encrypt offer?
1 Like
Yes, as mentioned above already, it's called a 'private CA', i.e., you set up your own trusted CA to issue client certificates. Where "CA" can also be just some OpenSSL CLI commands. Doesn't need to be fancy. The internet is full of guides on how to do it.
3 Likes
But that doesn’t help if the root for that is not in the set of common trusted roots in distributions, which is the entire point of this.
I wish I could ask you (LE) to stand up for internet (nōn-web) users and ask Google to change this, due to LE’s widespread use, but considering that ⓐ Google pays LE and ⓑ LE’s mission is web/https-only, I guess you won’t. Too bad.
The uproar is hundreds of Fediverse users who favourited and/or boosted my thread about this, FWIW, but it doesn’t seem you’re even vaguely concerned about breaking lots of small users’ use cases that right now just work. I don’t have the energy for this 
I'll state this very clearly: Google's sponsorship of ISRG plays no role in this decision.
In fact, if Google (or anyone else) sponsored Let's Encrypt more, it would be more likely that we could continue to offer client certificates. The issue is fundamentally one of time and resources. We are a small team offering a large service for free, and bifurcating that service to offer TLSClientAuth-only certificates is a significant amount of work -- not just work today, but work on an ongoing basis, for as long as we offer that service.
I'm truly sorry that this change impacts you negatively. I'm sorry that, ten years ago when Let's Encrypt started, we made what I now believe to be the mistake of including TLSClientAuth in our certificates so that an ecosystem came to rely on it.
But me being sorry can't change the facts on the ground. We don't have the time and resources to run a whole second hierarchy -- especially not for a few hundred users when our daily issuance is in the millions. And the vast majority of Trust Stores would never include that second hierarchy's root anyway. Please take the time remaining before the announced deadline to work with your peers on figuring out where mTLS is unnecessary, and where private PKIs can fill the gaps. I believe you'll find that this transition is easier to navigate than you expect.
16 Likes
TLSClientAuth-only certificates
That also wouldn’t help. We need one certificate for a server that can be used in both roles in an SSL connection, under a Root CA in the common roots in usual distributions.
1 Like
That's even more impossible.
A CA which can issue TLSServerAuth certificates can, in practice, only be in one of two states:
- Trusted by major root programs; or
- Untrusted.
If the root we used to issue these TLSServerAuth+TLSClientAuth certificates is trusted by major root programs, then it is subject to the same restrictions as our current roots, and would soon be forbidden from issuing TLSClientAuth certificates. So this doesn't help you.
If the root we used to issue these TLSServerAuth+TLSClientAuth certificates is not trusted by major root programs, then it will never be included in those trust stores of those "usual distributions". Groups like Debian don't have the time or expertise to run their own trust stores, so they copy the major ones (Mozilla, Apple, Microsoft, Google) and just follow them. There is zero chance that they would add a root that isn't trusted by one of those major programs just because we ask nicely.
And beyond that, the rest of my post above still stands. Per the requirements, our primary hierarchy is going to be TLSServerAuth-only. Operating a bifurcated TLSServerAuth+TLSClientAuth hierarchy has all the same costs as operating a TLSClientAuth-only one. We cannot do that.
8 Likes
No, as others have already explained, that is not an alternative to letsencrypt. That covers a much narrower range of uses, and with a lot more effort even for those uses where it does apply.
Can you share what your use-case is?
3 Likes
Can you describe your use case?
There's an awful lot of heat on this thread, but so far not one description of actual harm that inability to use LE certificates for client authentication will cause. Concrete details in this area may help motivate a solution.
5 Likes
That's a significantly higher bar, and far, far outside of LE's capabilities. Assuming that LE were persuaded to run a parallel root for DV client or DV server+client authentication, getting to the point that you describe here would then require negotiation with dozens of platform providers[1]. This process would take years.
Configuration changes by operators are unavoidable, the question is which changes to make.
Would that be this thread? I note that there also, no actual harm is described. Without a description of actual harm there's no reason for LE to make the very substantial investment that you're proposing, let alone for any sponsor to step forward and fund it.
i.e. of every platform that the community in question runs software on. You could of course take the position that it's only important to deal with the big ones and let the smaller ones get trampled underfoot... ↩︎
4 Likes
Why would you need this? Isn't this just a configuration issue in the software in question?
2 Likes
Hi @mirabilos and @oinbar,
Perhaps choosing another Free ACME Certificate Authority will work for you.
It's possible, but unlikely. Every one of those will want to continue putting its root certificate into Chrome, so will have to make the same change in due course.
2 Likes