5 ms·

Ending TLS Client Authentication Certificate Support in 2026

61 points by pabs3 1y ago

egberts1 1y ago
Aaaaaw shoot. There goes my private WireGuard client-side TLS certificate for tunneled SSH. Just need to bashify all the certificate creation ... again.
- throwaway81523 1y ago
  CA.pl has 9 lives.
- arccy 1y ago
  mkcert is pretty painless
  - egberts1 1y ago
    Yes. But I like my own certificate tool better. * Creating Root CA node * Creating Intermediate CA node * Creating 2nd Intermediate CA node * Renew Root CA node * Renew Intermediate CA node * Encrypt using ChaCha20-Poly1305 * Encrypt using Elliptic Curve Problem is OpenSSH 3.1 recently broke CLI syntax, so that needs fixing. Used JetBrain with Bash plugin for development. https://github.com/egberts/tls-ca-manage https://github.com/egberts/tls-ca-manage
- JCattheATM 1y ago
  Why are you tunneling SSH over WireGuard?
  - egberts1 1y ago
    "Scoping and corraling" Also ensures that source IP are not leaked, as well.
    - JCattheATM 1y ago
      I mean, the IP of the WG gateway is still seen...so that's just being used to SSH to somewhere else? Seems like overkill.
      - egberts1 1y ago
        You may need a tad bit more field experience in hostile networking. It's all about hiding what protocol is being used.
        JCattheATM 1y ago
        > You may need a tad bit more field experience in hostile networking. Or maybe I can just sense bs after a career in the field :-) > It's all about hiding what protocol is being used. And what, exactly, do you think the advantage is from hiding SSH traffic this way?
        egberts1 1y ago
        Profiling, or more concisely, anti-profiling.
bjornsing 1y ago
Why are client certs not more popular? They seem like a pretty clean abstraction compared to all the API keys and JWT tokens floating around.
- SoftTalker 1y ago
  Users can’t manage them and nobody has come up with software that can. I have worked with PhDs who can’t even manage ssh keys.
  - notpushkin 1y ago
    Tooling problem, as always.
  - thayne 1y ago
    If only there was a standard protocol for trading credentials and a CSR or equivalent for a signed certificate. Kind of like ACME for client certs that uses login credentials instead of dns. And maybe then browser support for logging in using that to create a client cert instead of setting a cookie.
    - et1337 1y ago
      In case anyone misses the joke, I think this is what passkeys are.
  - nirui 1y ago
    > PhDs who can’t even Not a good point. I've experienced PhDs who can't (even, some may add) write shell script. Maybe they just hate the syntax, or specifically the $ symbol, maybe both. But, they did do fine job otherwise and has successfully replaced me, a person who can write a bit shell script :(
    - SoftTalker 1y ago
      The point is that even very smart people in technical fields can just be bad at/not care/willfully refuse to use stuff like this. It's a non-starter for a general-purpose authentication mechanism if the user has to understand concepts such as "private" and "publc" keys. Even 2FA solutions like Google Authenticator are simple enough that you just need to scan a QR code but very few people use them and even fewer actually bother to print/save the backup emergency codes for use if they lose access to their auth device. People can (sometimes) handle passwords, and an emailed reset link if they forget.
GauntletWizard 1y ago
I strongly disagree with this change. You should probably never accept client certificates signed by Let's Encrypt, but I think that it normalized something very healthy in the ecosystem: issuing one certificate that acted as both server and client certificate. I have spent surprisingly little time on making this work in the TLS ecosystems of my clients, automatically building per-service TLS certificates - allowing a robust internal infrastructure of whitelisting client services while being simple enough for devs to implement themselves. What I really wanted to do, and have proof of concept'd with only slightly more time, is per pod certificates, identifying a service account. It looks like this is progressing in mainline - https://github.com/kubernetes/enhancements/issues/4317 https://github.com/kubernetes/enhancements/issues/4317 - albeit very slowly.
- ymyms 1y ago
  I am also bummed out by this change. I really like the idea of using a certificate as a single identity for a service. Things could connect to a service using normal TLS but the service could also authenticate itself to other services using mTLS. After this change I'd need a separate certificate for the service to use for mTLS.
deleted 1y ago
[deleted]
CaliforniaKarl 1y ago
> This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs.
deleted 1y ago
[deleted]
ChrisArchitect 1y ago
more discussion: https://news.ycombinator.com/item?id=44003349 https://news.ycombinator.com/item?id=44003349
throwaway984393 1y ago
[dead]
flowerthoughts 1y ago
> This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs. Many uses of client authentication are better served by a private certificate authority, and so Let’s Encrypt is discontinuing support for TLS Client Authentication ahead of this deadline. Makes sense, even if inconvenient. Client auth is something LE can't provide as much validation of, compared to server certs. Based on this: https://googlechrome.github.io/chromerootprogram/#322-pki-hierarchies-included-in-the-chrome-root-store https://googlechrome.github.io/chromerootprogram/#322-pki-hi... > To align all PKI hierarchies included in the Chrome Root Store on the principle of serving only TLS server authentication use cases, the Chrome Root Program will "phase-out" multi-purpose roots from the Chrome Root Store. Rationale lacking.
greatgib 1y ago
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.

61 points by pabs3 1y ago

Aaaaaw shoot. There goes my private WireGuard client-side TLS certificate for tunneled SSH. Just need to bashify all the certificate creation ... again.

throwaway81523 1y ago
CA.pl has 9 lives.
arccy 1y ago
mkcert is pretty painless
- egberts1 1y ago
  Yes. But I like my own certificate tool better. * Creating Root CA node * Creating Intermediate CA node * Creating 2nd Intermediate CA node * Renew Root CA node * Renew Intermediate CA node * Encrypt using ChaCha20-Poly1305 * Encrypt using Elliptic Curve Problem is OpenSSH 3.1 recently broke CLI syntax, so that needs fixing. Used JetBrain with Bash plugin for development. https://github.com/egberts/tls-ca-manage https://github.com/egberts/tls-ca-manage
JCattheATM 1y ago
Why are you tunneling SSH over WireGuard?
- egberts1 1y ago
  "Scoping and corraling" Also ensures that source IP are not leaked, as well.
  - JCattheATM 1y ago
    I mean, the IP of the WG gateway is still seen...so that's just being used to SSH to somewhere else? Seems like overkill.
    - egberts1 1y ago
      You may need a tad bit more field experience in hostile networking. It's all about hiding what protocol is being used.
      - JCattheATM 1y ago
        > You may need a tad bit more field experience in hostile networking. Or maybe I can just sense bs after a career in the field :-) > It's all about hiding what protocol is being used. And what, exactly, do you think the advantage is from hiding SSH traffic this way?
        egberts1 1y ago
        Profiling, or more concisely, anti-profiling.

bjornsing 1y ago

Why are client certs not more popular? They seem like a pretty clean abstraction compared to all the API keys and JWT tokens floating around.

SoftTalker 1y ago
Users can’t manage them and nobody has come up with software that can. I have worked with PhDs who can’t even manage ssh keys.
- notpushkin 1y ago
  Tooling problem, as always.
- thayne 1y ago
  If only there was a standard protocol for trading credentials and a CSR or equivalent for a signed certificate. Kind of like ACME for client certs that uses login credentials instead of dns. And maybe then browser support for logging in using that to create a client cert instead of setting a cookie.
  - et1337 1y ago
    In case anyone misses the joke, I think this is what passkeys are.
- nirui 1y ago
  > PhDs who can’t even Not a good point. I've experienced PhDs who can't (even, some may add) write shell script. Maybe they just hate the syntax, or specifically the $ symbol, maybe both. But, they did do fine job otherwise and has successfully replaced me, a person who can write a bit shell script :(
  - SoftTalker 1y ago
    The point is that even very smart people in technical fields can just be bad at/not care/willfully refuse to use stuff like this. It's a non-starter for a general-purpose authentication mechanism if the user has to understand concepts such as "private" and "publc" keys. Even 2FA solutions like Google Authenticator are simple enough that you just need to scan a QR code but very few people use them and even fewer actually bother to print/save the backup emergency codes for use if they lose access to their auth device. People can (sometimes) handle passwords, and an emailed reset link if they forget.

GauntletWizard 1y ago

I strongly disagree with this change. You should probably never accept client certificates signed by Let's Encrypt, but I think that it normalized something very healthy in the ecosystem: issuing one certificate that acted as both server and client certificate. I have spent surprisingly little time on making this work in the TLS ecosystems of my clients, automatically building per-service TLS certificates - allowing a robust internal infrastructure of whitelisting client services while being simple enough for devs to implement themselves. What I really wanted to do, and have proof of concept'd with only slightly more time, is per pod certificates, identifying a service account. It looks like this is progressing in mainline - https://github.com/kubernetes/enhancements/issues/4317 https://github.com/kubernetes/enhancements/issues/4317 - albeit very slowly.

ymyms 1y ago
I am also bummed out by this change. I really like the idea of using a certificate as a single identity for a service. Things could connect to a service using normal TLS but the service could also authenticate itself to other services using mTLS. After this change I'd need a separate certificate for the service to use for mTLS.

deleted 1y ago

[deleted]

CaliforniaKarl 1y ago

> This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs.

deleted 1y ago

[deleted]

ChrisArchitect 1y ago

more discussion: https://news.ycombinator.com/item?id=44003349 https://news.ycombinator.com/item?id=44003349

throwaway984393 1y ago

[dead]

flowerthoughts 1y ago

> This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs. Many uses of client authentication are better served by a private certificate authority, and so Let’s Encrypt is discontinuing support for TLS Client Authentication ahead of this deadline. Makes sense, even if inconvenient. Client auth is something LE can't provide as much validation of, compared to server certs. Based on this: https://googlechrome.github.io/chromerootprogram/#322-pki-hierarchies-included-in-the-chrome-root-store https://googlechrome.github.io/chromerootprogram/#322-pki-hi... > To align all PKI hierarchies included in the Chrome Root Store on the principle of serving only TLS server authentication use cases, the Chrome Root Program will "phase-out" multi-purpose roots from the Chrome Root Store. Rationale lacking.

greatgib 1y ago

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.