Today is the last day that #Letsencrypt will issue certificates with the "Client Authentication" EKU (Extended Key Usage).
-
Today is the last day that #Letsencrypt will issue certificates with the "Client Authentication" EKU (Extended Key Usage). If that sounds like obscure technobabble, you are mostly right. But it might cause some breakage in unexpected places where servers talk to each other (e-mail server, XMPP servers, mTLS (mutual Transport Layer Security) setups). Here's information for XMPP: https://blog.prosody.im/2026-letsencrypt-changes/
-
Today is the last day that #Letsencrypt will issue certificates with the "Client Authentication" EKU (Extended Key Usage). If that sounds like obscure technobabble, you are mostly right. But it might cause some breakage in unexpected places where servers talk to each other (e-mail server, XMPP servers, mTLS (mutual Transport Layer Security) setups). Here's information for XMPP: https://blog.prosody.im/2026-letsencrypt-changes/
If you rely on the Client Auth EKU, you will have to find a different Certificate Authority (CA) than Letsencrypt. Or run your own CA, which is certainly possible but adds another attack layer. Oh, by the way, this change is described as being *better* for security, which I find a bit of a confusing justification. Le sigh.
-
Today is the last day that #Letsencrypt will issue certificates with the "Client Authentication" EKU (Extended Key Usage). If that sounds like obscure technobabble, you are mostly right. But it might cause some breakage in unexpected places where servers talk to each other (e-mail server, XMPP servers, mTLS (mutual Transport Layer Security) setups). Here's information for XMPP: https://blog.prosody.im/2026-letsencrypt-changes/
@jwildeboer any information about what we need to do to keep our email server communicating?
At present I use my letsencrypt certificate. -
@jwildeboer any information about what we need to do to keep our email server communicating?
At present I use my letsencrypt certificate.From the link @jwildeboer posted, there is this detail:
However they have announced that they will be issuing certificates for only “server authentication” by default from 11th February 2026
From what I'm understanding, using Lets Encrypt certificates on an incoming SMTP server shouldn't change anything. Then using a certificate issued for server usage would be a better match.
If you use Lets Encrypt for client usage it might be different. However, if that will actually have an impact on Postfix as an outgoing SMTP server, that I'm not sure of. Generally speaking most SMTP servers have been fairly forgiving with the TLS communication.
The bigger challenge will be if you use Lets Encrypt on a client side, using it for authentication purposes against a strict TLS server on the remote end, which checks the EKU field and requires it to be set to "client authentication". This use case will break with the coming Lets Encrypt change.
-
Today is the last day that #Letsencrypt will issue certificates with the "Client Authentication" EKU (Extended Key Usage). If that sounds like obscure technobabble, you are mostly right. But it might cause some breakage in unexpected places where servers talk to each other (e-mail server, XMPP servers, mTLS (mutual Transport Layer Security) setups). Here's information for XMPP: https://blog.prosody.im/2026-letsencrypt-changes/
@jwildeboer What does this mean for services such as Synology DSM?
-
If you rely on the Client Auth EKU, you will have to find a different Certificate Authority (CA) than Letsencrypt. Or run your own CA, which is certainly possible but adds another attack layer. Oh, by the way, this change is described as being *better* for security, which I find a bit of a confusing justification. Le sigh.
@jwildeboer ZeroSSL, the other big ACME CA for free-certs, did remove Client Auth EKU already last October
-
R ActivityRelay shared this topic
