Brutkey

Jan Wildeboer 😷:krulorange:
@jwildeboer@social.wildeboer.net

The latest move by Google and backed by the CA/Browser Forum: no more "clientAuth" in certificates, only "domainAuth". While this sounds like an obscure technical detail, it has quite big consequences. "clientAuth" is used to connect services (mTLS) in clouds and beyond. The fact that every LetsEncrypt certificate has "clientAuth" made microsoervices work seamlessly. Now the CA/Browser Forum tells you that if you need "clientAuth" you should setup your own CA. Which is quite a burden.

4/6

Jan Wildeboer 😷:krulorange:
@jwildeboer@social.wildeboer.net

And while you might think "Opportunity! Let's create a CA a la LetsEncrypt for mTLS certs with clientAuth!", you will have a bigger problem. This decision by Google and the CA/Browser Forum means that they only accept root CAs in their pool that do NOT sign certs with "clientAuth" or any other EKU (Extended Key Usage) except "domainAuth". And yes, that includes the EKU "emailProtection" that you need for S/MIME certs. In case you wonder why I spent so much time on creating those ;)

5/6

Jan Wildeboer 😷:krulorange:
@jwildeboer@social.wildeboer.net

I will stop here and turn this thread into a full blog post soon where I will also add sources for everything I said. I think that the certificate ecosystem needs more attention and that we in the Fediverse should have some tough discussions on how the current system works. As enabler or limiter of federation the way we use it.

6/6

Jan Wildeboer 😷:krulorange:
@jwildeboer@social.wildeboer.net

Addendum: I've been thinking about this topic for quite some time. And I thought about possible alternatives to centralised trust stores in the certificate field. I put that on a website (with a letsencrypt certificate ;) at https://nerdcert.eu