Matthew McPherrinFeb 14, 2025

Chrome has published version 1.6 of their root store policy.

Notably, this contains a timeline for deprecating use of the TLS Client Auth extended-key-usage inside the PKIs included in their program.
If you currently use TLS Client Auth from a publicly trusted CA, you may need to take action.

> ... certificates issued on or after June 15, 2026 MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

https://www.chromium.org/Home/chromium-security/root-ca-policy/#32-promote-use-of-dedicated-tls-server-authentication-pki-hierarchies

Chrome Root Program Policy, Version 1.6

Show threadZashFeb 14, 2025
@mattm That sounds like trouble for #SMTP and #XMPP and anything else doing mutual certificate authentication between servers. 😟
Show threadCorsac
@zash @mattm isn’t ClientAuth mostly used for client (browser) authentication and maybe VPN clients? I think SMTP servers all use ServerAuth
Feb 15, 2025 at 12:13pmMastodon for iOS
Show threadZashFeb 15, 2025

@corsac @uexo I know that OpenSSL checks the certificate purpose based on whether you initialize a client or server context, and in #Prosody we have a tweak that flips the validation for one of them so that incoming server-to-server connections are validated as if it was an outgoing connection.

I also remember other servers requiring the clientAuth purpose, long ago, in the before Let's Encrypt times.

Hopefully it will not be a problem this time around.