Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The "client cert" requirements were specifically not a CABF rule because that would rule it out for everyone complying with those rules, which is much broader than just the CAs included in Chrome.

Some CAs will continue to run PKIs which support client certs, for use outside of Chrome.

In general, the "baseline requirements" are intended to be just that: A shared baseline that is met by everyone. All the major root programs today have requirements which are unique to their program.





Thanks for chiming in! I remember now that you also said this on the LE community forum.

Right, that explains it. So the use would be for things other than websites or for websites that don't need to support Chrome (and also need clientAuth)?

I guess I find it hard to wrap my head around this because I don't have experience with any applications where this plus a publicly trusted certificate makes sense. But I suppose they must exist, otherwise there would've been an effort to vote it into the BRs.

If you or someone else here knows more about these use cases, then I'd like to hear about it to better understand this.


Are you asking why an HTTPS server would need to use client auth outside of the browser? The answer is mTLS. If you want to use one cert for your one domain to serve both "normal" browser content and HTTPS APIs with mTLS, your cert needs to be able to do it all.

The server that wants to authenticate clients via mTLS doesn't need the clientAuth EKU on its certificate, only the clients do.

Most of the time you set up mTLS by creating your own self-signed certificate and verifying that the client has that cert (or one that chains up to it). I'm wondering what systems exist that need a publicly trusted cert with clientAuth.

Only think I've heard of so far is XMPP for server-to-server auth, but there are alternative auth methods it supports.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: