3 ms·

Wtf, so now you will not be able to use the same cert for bidirectional TLS connection. And this is totally a free user hostile change with dubious justificati

Wtf, so now you will not be able to use the same cert for bidirectional TLS connection. And this is totally a free user hostile change with dubious justification. Each service that will accept the client cert can decide or not to accept a root certificate. And chrome is not even on the server side, so I don't understand why they have a say in what should be acceptable by a server (except the monopoly they have on the client to be able to refuse certs with this flag). So now you will have to pay again legacy cert authorities to be able to use TLS client cert. Just to be put in perspective with the recent changes pushed by the same actors to enforce a reduction in validity duration of certificates to short periods, like less than a year when you need to constantly go back to your official root cert authority. All of that without a valid widespread problem that they would be trying to fix. In addition, letsencrypt could continue to support a dedicated profile for that but they won't. Discontinuing something they even already created to fix the issue. So TLS client cert will become a "pro" limited feature...

aaomidi 1y ago
It really doesn’t make sense to have the client cert be issued by a publicly trusted CA. What’s the assertion being made with that client cert?
- greatgib 1y ago
  If you can connect to "node1.mydomain.com" and your web browser believe that the server is legitimate because of the CA signature, why a server that would receive a request from "node1.mydomain.com" as certified by the CA signature of the client certificate would worth less than the other one? For a simple example, let's suppose that you would want to use "client certificate" who can access webhooks API that will be pushed to your server.
  - aaomidi 1y ago
    I guess that’s one context where it makes sense. The reason I have difficulty with public CA provided certificates for client certs is that client certs aren’t primarily being used as authentication of a specific user (and maybe authorization). While in servers, certs are practically only being used for authenticating a connection to an endpoint. The issue here being that delegating client cert auth to a third party (Public CAs) means that you’re pushing the problem of monitoring the CA ecosystem to that client. A client that is limited and restricted by the rules of public CAs. But I guess this isn’t that different from OAUTH with a third party IdP.

aaomidi 1y ago

It really doesn’t make sense to have the client cert be issued by a publicly trusted CA. What’s the assertion being made with that client cert?

greatgib 1y ago
If you can connect to "node1.mydomain.com" and your web browser believe that the server is legitimate because of the CA signature, why a server that would receive a request from "node1.mydomain.com" as certified by the CA signature of the client certificate would worth less than the other one? For a simple example, let's suppose that you would want to use "client certificate" who can access webhooks API that will be pushed to your server.
- aaomidi 1y ago
  I guess that’s one context where it makes sense. The reason I have difficulty with public CA provided certificates for client certs is that client certs aren’t primarily being used as authentication of a specific user (and maybe authorization). While in servers, certs are practically only being used for authenticating a connection to an endpoint. The issue here being that delegating client cert auth to a third party (Public CAs) means that you’re pushing the problem of monitoring the CA ecosystem to that client. A client that is limited and restricted by the rules of public CAs. But I guess this isn’t that different from OAUTH with a third party IdP.