Re. Ending TLS Client Authentication Certificate Support in 2026
Do not remove that! It is required for SMTP (the sending MTA must have that in its certificate for the receiving MTA to consider it a both-sides-authenticated connection).
It’s also useful on the web (and I’ve seen it used), but it is absolutely crucial for SMTP, for which people generally use the same key/certificate on the same box.
Can you link to an RFC that describes this requirement? If your assertion is correct, i would like to learn is about it.
It’s observed behaviour of SMTP servers in real life. IIRC it was CAcertStartSSL who (at first?) lacked this EKU and that broke peer auth in SMTP STARTTLS.
(That’s not to say there’s no RFC on this, it’s just I don’t tend to have RFC references handy.)
I'd be interested in hearing more details about this. As I understand it:
smtpd_tls_ask_ccert) and typical behaviour is for SMTP servers to not request, let alone require, a client certificate.It sounds like I may be wrong about one of these. Could you please expand on what problems happen when an SMTP session is not mutually authenticated?
Yes, with Postfix you have to enable that it uses them in the config. I think that is smtpd_tls_ask_ccert = yes plus smtpd_tls_received_header = yes.
In sendmail, however, this is the default, and it actively displays verification FAIL in the Received header if the certificate of the sending MTA isn’t qualified as TLS client (which it is, in this setting, even if it by itself is a server).
This can be generalised to all machine–machine communication (whereas the cited use of webbrowsers is generally human–machine only)… incidentally also for HTTPS where API use is secured by SSL certificates and the endpoints are both servers (and as such both qualify for an LE certificate with domain validation). One setting I’ve actually set up is using a smarthost for outgoing eMail, and the smarthost verifies the sender with certificates (as SASL is much more expensive and increases the attack surface).
As to the note having no consequences… that’s not entirely true. They give the instance (human, or a script or something) looking at the header extra confidence (that the mail was not intercepted, spoofed, etc.), and it’s possible (with extra configuration) to require this for specific communication (e.g. family-internal communication).
Thanks for the additional info! This is the part I'd like to explore further. How common are configurations that do something based on this confidence level, or otherwise require mutual authentication?
I've mostly heard of this in custom configs negotiated between two enterprises in regulated fields (like banking or medical), or otherwise set up by people who deeply understand SMTP (like your example of mTLS to a smarthost).
I’m not “an enterprise”, and I suspect that there’s quite some amount of nōn-commercial small mail server operators have set up something like this, at least as opt-in, and these would be hurt the most from that. Perhaps not as big as it could, considering it’s not enabled in Postfix by default (though I have been pondering asking for that to change as it makes SMTP generally more useful), but I could see it as extra qualifier for spam classification if nothing else.
On the bigger player but not so big they wouldn’t use LE or FOSS MTAs side, maybe. Probably less so in the eMail business but possibly more in getting inhouse boxen (with no external DNS, LE certificates obtained with DNS challenge) to send eMails out. Smaller players would most likely whitelist the RFC1918 IPs, but with things moving to VM providers or now the cloud…
Securing APIs… is actually pretty easy to do with this, considering the client cert info (if not required on Apache httpd level already) is passed to CGIs and CGI-like things, which can then use that to check access. It’s a rather cheap way to do that as well when every box already has a certificate for serving https or so anyway.
All of these are things people tend to do “inhouse”, so you wouldn’t see them on analysēs or even advertising material about companies.
Setup in sendmail, for reference, looks like this:
CERTIssuer:/C=US/O=Let's+20Encrypt/CN=R3 SUBJECT to the access “database” (plaintext file, hashed), saying that if a client certificate is presented and issued by this, check further below.CERTSubject:/CN=foo.example.org RELAY per box, telling sendmail that this particular host may relay.LE does the authentication, so we assume that any LE-issued certificate with that hostname really belongs to that host.
And that’s really all needed to set this up (besides the usual pointing it to the right key, certificate and chain files and roots directory, which you want anyway). So it doesn’t need “deep understanding”.
I’m sure other services do it similarily. I’ve even used that for OpenVPN, no need to roll my own CA!
I just thought of another use case that ISTR requiring this: Jabber (XMPP) S2S connections, which are also machine-to-machine. I’m not 100% sure about this, could be that they just operate unidirectionally and call back for the other direction so only the SSL servers have their certificate checked.
I don’t use Matrix so I don’t know how they do that.
It was StartSSL, not CAcert, which had the problem. Several people replied in the thread, and I can only assume more people started other threads or contacted their support address about it.
The root of this discussion seems to be about how client certificates are trusted, no? Anyone can issue a client certificate but conventionally to trust a client certificate you have to tell the receiver to trust a specific certificate/public-key, or it needs to come from a trusted issuer [which can be a private CA].
If your receiver is currently configured to trust certs from a public CA (rather than trusting specific known certs/public keys), are there other public CAs who offer client certificates? How did it work before Let's Encrypt?
I was concerned about this too as my only current use of Let's Encrypt is on my mail server, for IMAPS as server and for SMTP STARTTLS as all of MX server, submission server, and MX client, but on reflection I think it's a non-issue.
At least for the public exchange of email messages routed via MXs, authentication of the domain-name used by a client is a clear non-issue:
The question of authenticating SMTP clients who are connecting to submit a message for delivery (MUAs, or what we usually think of as "email clients") using SMTP TLS with client authentication is an interesting one for IETF[2], but is outside of Let's Encrypt's scope because Let's Encrypt only performs domain validation (DV); there's no concept of certificates for individual users who share a domain.
The separate hypothetical question of developing protocols that support public exchange between strangers who control domain names and require mutual authentication (described above as "generalised to all machine–machine communication") is better addressed by getting away from CA-based PKI altogether and instead using something like DANE TLSA (RFC 6698).
1: During DMARC's early adoption there was a definite "If SPF then why not SMTP TLS?" sentiment, but the view at the time was that:
2: e.g. If RFC 8601 supports reporting SMTP AUTH results, why does it not support reporting SMTP TLS client authentication results?
No, the root is that a certificate can only be used by the client side in an SSL connection if this key usage is set by the issuing CA, and that certificates that lack this cannot be used in all places certificates with it can, and that that has real impact on people.
We have two separate cases to think of here.
One is simple client verification, optional in the normal SMTP case, mandatory but all senders permitted in the XMPP case.
For this, you generally have a root CA store (/etc/ssl/certs or what have you), and the certificate and the intermediates sent by the client. You do the same as a browser, check the certificate and the chain and do a CN match in the DN, only that the client initiated the connection, not you, but that’s not a problem for these use cases, and MTAs generally also check reverse and forward-of-reverse DNS as well.
The other use case is authorisation from the client certificate, where you trust the CA to have done authentication.
Here, you indeed have to allowlist permitted client certificates… but instead of listing their hashes, or trusting all certificates issued by a special-use CA (like OpenVPN’s “easy-rsa” does), you say “for the certificates with DNs X, Y and Z issued by (say) LE, allow”.
This makes configuration super-easy, robust in the face of renewals, and has a lot of appeal.
Grepping for CERTIssuer in the RCS history of /etc/mail/access on one machine, I see that I’ve used in the past:
/C=US/O=Let's+20Encrypt/CN=R3/C=US/O=Let's+20Encrypt/CN=Let's+20Encrypt+20Authority+20X3/C=GB/ST=Greater+20Manchester/L=Salford/O=COMODO+20CA+20Limited/CN=COMODO+20RSA+20Domain+20Validation+20Secure+20Server+20CA (this was a multi-year one a friend (thanks rsc!) paid for)/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,+20Inc./OU=http://certificates.godaddy.com/repository/CN=Go+20Daddy+20Secure+20Certification+20Authority/serialNumber=07969287 (this was one I paid for IIRC)/O=Root+20CA/OU=http://www.cacert.org/CN=CA+20Cert+20Signing+20Authority/emailAddress=support@cacert.orgAnd, as you can see from the thread I linked above, I was angry at StartSSL for being the outlier and not supporting this.
People do that, if alone as an extra identifyer of being a proper message or spam/scam.
Except this is not true. LE verifies hostnames, and it’s hostnames that are used in this purpose, not domains. The assumption here is that all users of a given host (usually just the one, in the traveller’s laptop case, but can be more) with access to the system sendmail share the same level of access to the mailserver regarding sending out eMails, and this is true for many cases. It’s also important for “system mails” (think cron(8), or SMART warning of a dying HDD).
If the users are virtual, they will generally not have direct access to the system MTA and therefore not able to use the SSL key and certificate to authenticate.
For proper users, let’s say cron(8), the flow is as follows:
cron(8) invokes sendmail(8) as MSA and gives it the mailsendmail(8) as MSA queues this up in /var/spool/clientmqueue::1 as local client without a client certificate, and the message is accepted by the MTA because localhost is a trusted sendersendmail(8) running as MTA (dæmonised) queues this up in /var/spool/mqueue(Note that sendmail(8) can also be Postfix, OpenSMTPD or whatever. It’s the name of the interface.)
The sendmail(8) running as MSA does not have access to the key material because it runs on behalf of a local Unix user. The user calls it, the process starts, queues (and optionally directly delivers to the MTA) the message, and immediately terminates.
The sendmail(8) process running as MTA, on the other hand, is started as a system dæmon, long-running, and does have access to the key material.
For some use cases, perhaps. But we don’t need to invent anything new because this has worked for decades with SMTP and XMPP. Just don’t break what already works for no reason.
DANE is a much newer thing, but the beauty is that you can choose what works for your scenario. Some people choose SMTP AUTH, which works better if you have large virtual user databases, LDAP perhaps, with Cyrus or Dovecot, but the simple setups where everything is Unix users anyway is much better served with TLS client certificates and UW imapd.
Sorry yes I was mentally skipping ahead past Let's Encrypt's issued certificates and talking more about how do you decide which client certs (with the correct key usage set) are trusted and from your further response it sounds like running your own CA is an option? That would seem conventional for mTLS type scenarios, but I haven't administered a mail transport since 1999.
I think my question is really why use Let's Encrypt specifically, for client certs, instead of your own CA, and is it just because they are easy to trust or is to because you need trust between two different unrelated organizations?
Do Gmails, Hotmails/Outlooks, Yahoos, iClouds of the world send their certificate for mTLS when they deliver mail? Do they require/accept a certificate for mTLS when they accept mail?
Sure, I didn't say people don't, just that there's no expectation, and that no material problem is solved.
It's not a useful test for spam or scams because criminals can register domains and obtain certificates from LE too. The only thing that LE tells anyone is that the possessor of the private key is the legitimate controller of the domain that appears in the certificate. That's it.
I was using "domain" as short hand for "domain name", which is what LE validates (thus "DV" not "HV").
This distinction changes nothing however; LE has no way to issue separate certificates for joe@example.com and fred@example.com. It can only issue a certificate for example.com, or e.g. mail.example.com. There is no concept of individual user certificates.
This example seems irrelevant; the submission process is internal to a host and doesn't use TLS at all. My claim was:
which is unrelated to sendmail's intra-host mechanisms.
Again, your response does not appear to address what I wrote. XMPP and SMTP aren't hypothetical. My point was clearly about hypothetical cases and I believe that it stands.
You do raise an important point ("Just don’t break what already works for no reason") that's worth addressing:
On the information so far, there's no problem that's worth LE spending resources to solve.
1: >3B people rely upon Chrome to secure their some of their most sensitive communication.
And note that, even if we were to do this, we would have to provide ServerAuth and ClientAuth on separate certificates which chain up to separate roots. We would, in effect, be operating a second private, untrusted, TLSClientAuth-only PKI which operators of servers which enforce mTLS could manually choose to trust. It would be little different from operating your own private CA to issue such certificates.
Chiming in quickly to add to the above... and coming from the perspective of someone who managed a few larger email deliverability projects (10MM+ daily emails):
mTLS support is not widespread or well developed across major MTAs. Exim, for example, has extremely limited support as compared to other systems.
mTLS on SMTP is rarely based on Domain Validation or the hostname on the cert, instead it is usually based on recognizing the issuing CA or the Certificate as being a permitted client for that server. It is mostly used for SMTP relay, wherein the Certificate provides for basic authorization to the server, and the Certificates act very much like Cloudflare's private Origin Certificates. Private CAs are typically preferred, because it greatly minimizes the amount of work and validation. This is due to a few reasons:
DMARC + DKIM + SPF is the industry standard way to ensure an email originated from the sender's approved servers.
Looking at the recent LetsEncrypt email about ending TLS Client Auth, the headers show it going through these systems:
gt214.mta.exacttarget.com
bounce.s11.mc.pd25.com
postfix-inbound-v2-1.inbound.mailchannels.net
inbound-egress-10.mailchannels.net
pdx1-sub0-mail-mx211.dreamhost.com
The DMARC policy set the requirements for SPF and DKIM.
The SPF policy allowed those domains and servers to route the mail.
The DKIM policy ensured the email actually originated from LetsEncrypt
Note the email originated on ExactTarget, which is a permitted sender for LetsEncrypt on the SPF policy and was signed by the associated DKIM policy - both of which are published on LetsEncrypts DNS records.
Trying to handle any of that with mTLS instead would be onerous. There would be no benefit to adding mTLS into that stack. Systems would have to be constantly updated to declare which hostnames are permitted, as they can come from any registered domain (wildcarding subdomains is not an option).
This is a complex problem. It is so complex, the industry realized mTLS wasn't a viable solution and settled on a mixture of locking down relays with private certificates for background transport, and DMARC+SPF+DKIM for user verifiable proof.
I need to stress this point too - DKIM not only proves the message originated from the domain, but does so in a way the end user has cryptographic confirmation on the message itself. There isn't anything standardized to record on the email the message's source was authenticated via mTLS at the various points. There also isn't anything standardized within that concept to associate a delegated sender (such as exacttarget, or a cloud email platform like branded gmail) with the originating domain. One would still need to deploy DMARC+SPF+DKIM to achieve all this, so layering in a domain based mTLS just creates a lot more work and maintenance for questionable and negligible benefits.
That's not quite the case. mTLS between strangers requires a public CA. LE is credible, is widely-trusted, and — subject to its own budget priorities — has the technical capability to do it securely. A random organisation spinning up a public CA now to fill the gap would likely fail all of that:
The fact that the 800 lb gorilla in the browser space is now mandating root certificates that are incapable of mTLS use invalidates the piggy-backing strategy that approximately every other application of TLS PKI has taken, at least to bootstrap: copy the trusted CA set from a major browser[1]. This strategy is (or at least was) so entrenched that when Oracle began requiring direct agreements as a condition of including root certificates in its Java runtime, there was considerable angst. It was seen by many as presumptuous and unreasonable. It was neither of these things, but the response is evidence of how the trust anchors selected by browser vendors are seen; then and now. While as engineers we might be tempted to dismiss such perceptions as irrelevant, they are in fact the basis of most trust.
If LE were to elect to make DV client certificates available separately, I'd suggest that any communities that depend upon them for mTLS would take the change in stride as a minor configuration tweak. For organisations which already trust LE (which is already approximately all organisations who use the Internet) it would simply be an accommodation of a change caused indirectly by a giant elsewhere in the ecosystem.
None of this is to claim that the problem is material, let alone that LE is in any sense obliged to continue to serve large mTLS-between-strangers communities if they exist, only that there's an enormous difference for any such communities between LE or another widely-trusted CA offering the option and someone else spinning up a new public CA[2] in haste to fill the gap.
1: This copying may be indirect. Most/all Linux distributions include a trusted CA set that dozens/hundreds of applications simply use as-is rather than establish their own trust root e.g. by copying a browser's set. Presumably other operating systems do much the same.
2: I've not checked the details, but any other CAs who have the client EKU turned on in their certificates are facing the same issue in order to continue to put their root certificates into Chrome. mTLS-between-strangers communities will now be facing this problem approximately simultaneously on all fronts. I do wonder how long it might take such communities to implement DANE TLSA...
Apologies, but we appear to be talking past each other. I don't dispute this point at all. My point is that a TLSClientAuth-only root operated by Let's Encrypt would effectively not be a public CA.
Sure, it's operated by LE, an organization that many trust already. But that relationship would not be programmatically visible, since the TLSClientAuth-only root cannot be cross-signed by the existing trusted TLSServerAuth hierarchy. And as you say, the vast majority of trust stores around the world are just copy-pasted from various browser trust stores, which also would not include this new root.
So in order for the new hierarchy to be trusted, everyone who cares about mTLS would need to be manually augmenting their trust stores anyway, at which point it's clearly not a publicly trusted root, it's a private PKI like any other.
Thank you, and you're quite right, we're using the term "public CA" with different meanings. My apologies also, I should have picked this up myself. Rather than plumb the depths of a semantic argument which I suspect will yield an entire spectrum of CA publicness levels[1], I'll rephrase:
The client authentication part of mTLS between strangers requires a CA who is widely considered trustworthy and whose certificates are intended to be relied upon by anyone (the public). For a community of strangers which currently uses LE certificates to achieve mTLS[2], a party who is not already a widely-trusted CA spinning up a CA to fill the gap would be an enormous and likely-infeasible undertaking, particularly without the backing that LE has. Again, I'm not suggesting that LE is in some sense obliged, just clarifying that the requirement is for a technically capable (and therefore well-funded) CA who intends that its certificates be relied upon by strangers (the public) and who is widely trusted to do so.
In all probability, the same operating system vendors who are taking LE's existing root certificates would willingly take client-only root certificates as well. It's just a configuration change, to receive an additional certificate from a CA already seen as trustworthy. It is a reasonable objection that this will not happen soon enough to resolve the problem, even if LE were to publish such a root certificate tomorrow.
So, yes, per-relying-device configuration will be required, but the requirement would not be served by "a private PKI like any other". A CA trusted by tens of thousands of strangers is part of the requirement. Hopefully I've now conveyed the distinction?
(Still open is the question of whether this is a material problem for anyone to begin with. XMPP has been mentioned, but no compelling argument yet put forward, in particular no description of the resulting harm.)
1: From my perspective, it looks as though you're engaging in a faulty generalisation: that all private CAs require relying-device configuration, therefore all CAs that require relying-device configuration are private CAs. All dogs are animals, therefore all animals are dogs. Per the rephrase above, what I was getting at was the expected non-relationship between the CA and the relying parties (the public):
I think we'd both agree that an internal CA for a 10,000-person organisation that issued a device certificate and installed its own root certificate on personnel devices as they were onboarded, and installed its own root certificate in the trustbase of the relevant internal servers, was a private CA. The subjects that it's willing to certify and the intended relying parties are all its personnel. No public participation on either side is intended.
I think we'd both agree that LE operates a public CA, at least with respect to certificates acceptable to Chrome. We appear to be differing specifically on whether this would still be true for LE-issued certificates that were not acceptable to Chrome.
I'd suggest that there's a non-hypothetical example of a public CA for whom per-device configuration is generally required: CAcert. Their certificates are available to anyone, subject to identity and security requirements. Their root certificates are intended for reliance upon by strangers (the public). While they've clearly not achieved what they set out to do, I'd suggest that it would be a bit of a stretch to claim that they were not a public CA.
I intuit dozens of additional potential configurations of relationships, with varying degrees of publicness on both the subject and relying party sides, and therefore that efforts to bottom out the semantic argument won't get us anywhere.
2: SMTP MX operators would have been an example but — as mTLS doesn't solve a relevant problem — client authentication is unimportant there, even if it's happening opportunistically at present. XMPP server operators may be an example.