Re. Ending TLS Client Authentication Certificate Support in 2026 Do not remove that! It is required for SMTP (the sending MTA must have that in its certificate for the receiving MTA to consider it a both-sides-authenticated connection). It’s also useful on the web (and I’ve seen it used), but it i…

[image] mirabilos: As I already wrote (!), sendmail does support separate files, but e.g. Jabber servers generally don’t (verified for the one I use). Then maybe this should be a feature request towards your Jabber server.

Not in time for this. Even assuming people run current operating systems (which they don’t, for reasons), a vast majority won’t see anything that gets implemented within the year before early-to-mid 2028, due to distro release cycles.

I don't know that there is a big overlap in the Venn diagram of 'CAs who will still issue with clientAuth because they don't care about Chome' and 'will sell or make available a certificate to subscribers' and maybe 'CAs who put the effort in to stay in all the none-Chrome trust stores'. clientAuth…

I don't understand how you accept your Jabber server to not support this (at least not for the forseeable future), while on the other hand you demand a CA to adjust to your expectations.

[image] agowa: I'd still be interested how the Chrome Root Program wants to handle all of the eIDAS CAs then. They're issuing website certificates that are also used for server-to-server API requests in PSD2 after all... They already have their own EUTL trust store and do not rely on copying …

I put together a quick script to find certificates trusted by Apple/Mozilla/Microsoft that aren't trusted by Chrome. It doesn't take into account cross signs but it does show some relevant CAs. Apple and Microsoft include CAs like: SSL.com Client ECC Root CA 2022 (in Apple/Microsoft) HARICA Clien…

I don’t understand why it’s so hard for people to get the expectation that THINGS THAT CURRENTLY WORK JUST CONTINUE WORKING, i.e. don’t break existing users, period. Even the Linux kernel doesn’t do it, even if people occasionally try.

SSL 3.0, TLS 1.0, SHA-1 certificates, ... also worked at some point, but are largely not supported anymore today. The Internet is not a static environment.

If the public WebPKI was never willing to break existing systems, we'd still be in a world where publicly trusted CAs issued certificates for localhost and used encryption algorithms that are now known to be weak. Yes, change makes things more difficult. But the only thing worse than change to make…

[image] mirabilos: I don’t understand why it’s so hard Are you actively discussing this issue at any XMPP, XSF, and/or Jabber forums? I think that entire community is best engaged to figure out a way forward. Let's Encrypt staff has been very clear on their plans. Involving the experts for…

Do NOT remove TLS Client Auth EKU!

Feature Requests

mirabilos June 10, 2025, 11:29pm 128

That’s one of dozens of implementations.

Topic		Replies	Views
Let's Encrypt, ACME challenges, and ExtKeyUsage=ClientAuth Issuance Policy	15	2086	August 7, 2023
extendedKeyUsage "TLS Client Authentication" in TLS server certificates Issuance Tech	16	9139	May 11, 2018
EKU of Root Certificate ISRG/Organizational	32	5584	July 19, 2022
Certificates with single EKU Issuance Policy	9	637	March 27, 2025
Help, let'sencrypt does not work for Mail Help	19	4522	June 1, 2022

Do *NOT* remove TLS Client Auth EKU!

Related topics

Do NOT remove TLS Client Auth EKU!