On Tue, Jan 27, 2026 at 07:15:56AM -0000, Stefan Langeder via Exim-users wrote:
> I have a question regarding [client] certificate validation:
>
> I found following error in our exim logs:
>
> SSL verify error: depth=0 error=unsuitable certificate purpose cert=***
>
> It seems the problem is that we use an ACL with the condition
> “verify=certificate” and that the certificate used by the sender is
> missing the certificate extension “Client Authentication
> (1.3.6.1.5.5.7.3.2)” .
>
> My question is: Is there any way to configure exim to ignore that the
> certificate extension is missing?
As noted by Jeremy below, CAs in the Google root store programme are
phasing out support for issuing TLS client certificates, so validating
TLS client certs as issued by a trusted CA is going to be increasingly
difficult, unless they're issued by your own private CA.
But the good news is that that it never reall made sense to trust a
3rd-party CA to authenticate your trusted clients to your server. The
most sensible way to use client certificates is to have your ACLs be
based not on what some CA asserts, but rather on the client's public key
fingerprint, directly stored in your ACL table. All it takes is for
the client to maintain a stable key, that changes infrequently, and
only in coördindation with your server (adding ACL entries for upcoming
new keys before the client deploys them in production).
On Tue, Jan 27, 2026 at 01:08:49PM +0000, Jeremy Harris via Exim-users wrote:
> On 2026/01/27 7:15 AM, Stefan Langeder via Exim-users wrote:
> > It seems the problem is that we use an ACL with the condition
> > “verify=certificate” and that the certificate used by the sender is
> > missing the certificate extension “Client Authentication
> > (1.3.6.1.5.5.7.3.2)” .
> >
> > My question is: Is there any way to configure exim to ignore that
> > the certificate extension is missing?
>
> There's nothing specific for permitting a cert that lack the status of
> "usable for client authentication" to be used for exactly that, no.
>
> You could make the entire verification optional (main-config option
> tls_try_verify_hosts), and (preferably) add in some specific checks on
> connections from those hosts e.g. in your acl_smtp_mail ACL.
I assume Exim can implement client access control based on client public
key fingerprints (SHA2-256 digests of the DER SPKI), obviating the need
to drag in CA-based trust.
While, the server's TLS library (e.g. OpenSSL) might no longer consider
the certificate to have be a trusted CA-issued certificate, the
handshake can still complete if certificate verification is disabled,
and then the public key fingerprint can be used directly to drive the
srever's access control logic.
It is in principle possible to modify Exim (write some code) to pretend
that the certificate check is a server certificate check when its
extendedKeyUsage has the "serverAuth" (OpenSSL nomenclature) EKU, and
not the "clientAuth" EKU, but perhaps that's not a good idea, since in
most cases you really should not trust some random 3rd-party CA to tell
you who your trusted clients are.
--
Viktor. 🇺🇦 Слава Україні!
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## [email protected]
## Exim details at https://www.exim.org/
## Please use the Wiki with this list - https://code.exim.org/exim/wiki/wiki
