There is no “community”. Communication between beforehand unknown
to each other systems must work, just like on the web.
Or are you asking that users visiting websites need to make up a
private CA with the website operators beforehand? No, you don’t.
Discussions have already happened on the github ejabberd issues Inabiltiy to s2s on next generation letsencrypt certifiates (X509v3 Extended Key Usage: ONLY TLS Web Server Authentication) · Issue #4392 · processone/ejabberd · GitHub with the recommendation to enable mod_s2s_dialback.
Not removing the client auth EKU will result in breaking existing users who want a certificate that works with Chrome.
That’s one of dozens of implementations.
Tbh, the issue is not it being "decommissioned" in itself but the too short timeline. If it was 2028 or 2029 it wouldn't really have been that big of a deal. Then it would have been easy to get required changes into each and every distro but not even half a year until the first CAs drop it and 2026 for the complete removal? Sorry but that is just way too "not-considerate" of real world usages. I don't see any real world security implications of having "clientAuth" and "serverAuth" in server certificates at all. Let alone one that justifies breaking so many things and causing such big issues in industries you don't care about...
But they were included in Chrome because qwac (Qualified website authentication certificate) were seen as equivalent to EV certs and used for both the server-to-server APIs as well as client-to-server. Especially because both are REST-APIs in the case of PSD2 in the finance sector for example...
That's why I asked if Chrome is going to remove them then. Will be a kinda shitty experience paying for things when you get redirected either through or a website tries to make API-calls towards a payment service provider and the QWAC certs aren't trusted by Chrome anymore then...
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.