On Mon, Mar 23, 2026 at 02:33:52PM +0000, Salz, Rich wrote:
> Since WebPKI CA’s will not be able to issue TLS-Client certificates,
> what are the customers and CAs thinking of doing?
>
> Replies to [me?] will be summarized to both lists. Please be careful
> if you use reply-all.
[ Below, surely a longer answer than solicited. TL;DR, a workaround may
soon be added in Postfix 3.12 dev snapshots, that avoids the issue by
accepting serverAuth certificates from SMTP over TLS clients. ]
Some Postfix users have been asking what to do in their server-to-server
mutual authentication use-cases now that they can no longer obtain TLS
client certificates from WebPKI CAs.
In many cases their choice to rely on the WebPKI for their use-case was
a design mistake, and the certificates in question should have been
privately issued in the context of an existing bilateral relationship
between the parties involved.
That said, I think there are some residual use-cases of server
"cliques", where multiple independent organisations arrange for mutual
authentication of email transport between their various systems, with
the certificates in question issued by a carefully chosen small set of
CAs.
In case those CAs nevertheless have to abide by the new Google Root
program rules, I have prepared an optional workaround for inclusion in
next years 3.12 Postfix release. The documentation does its best to
warn users to avoid misuse. If it proves useful, it may even be
backported to a future 3.11.x patch release.
When the workaround is enabled, a Postfix SMTP server will accept a
TLS client's certificate that contains only a "serverAuth" EKU with no
accompanying "clientAuth" EKU. This is done by asking to the TLS
library to validate a server certificate chain, instead of a client
certificate chain.
The patch is small enough to include below, in case anyone is curious
how this is done. I do expect this is likely to be misused by some,
but it may be useful to others who've read the documentation and
verified that the workaround addresses their use-case.
--
Viktor. 🇺🇦 Слава Україні!
diff --git a/proto/postconf.proto b/proto/postconf.proto
--- a/proto/postconf.proto
+++ b/proto/postconf.proto
@@ -20651 +20651,36 @@ type to a non-Berkeley-DB type. </p>
<p> This feature is available in Postfix ≥ 3.11. </p>
+
+%PARAM tls_trust_server_ccerts no
+
+<p> Whether to trust client certificates whose extended key usage (EKU) lists
+only <b>serverAuth</b> and not <b>clientAuth</b> as valid TLS client
+certificates. This parameter is used only in the SMTP server, when client
+certificates are requested via smtpd_tls_ask_ccert or smtpd_tls_req_ccert.
+It is a workaround for policy changes at the major WebPKI CAs that preclude the
+issuance of certificates with a <b>clientAuth</b> EKU. </p> </p>
+
+<p> In almost all cases the default value of <b>no</b> should not be changed.
+When TLS client certificates are used to extend the right to send outbound mail
+to remote clients in possession of a trusted key pair, the public key
+<b>SHOULD</b> be trusted <i>directly</i>. This is done by using the public key
+digest (see smtpd_tls_fingerprint_digest) as a lookup key with
+check_ccert_access. Various third-party CAs should not be in a position to
+decide which client systems are part of your extended network. </p>
+
+<p> The <b>yes</b> setting should only be used when TLS certificates are used
+to implement mutual authentication within a clique of independent peer systems
+that perhaps trust each other to not transmit spam, or to be allowed to reach
+otherwise restricted mailboxes, etc., but where it is impractical for each
+receiving system to issue long-term stable keys to each trusted sending system,
+and a suitable CA or small set of CAs is trusted to issue certificates to each
+of the peers. Trusting every WebPKI CA is likely unwise in this context. </p>
+
+<p> When this parameter is set to <b>yes</b>, the Postfix SMTP server will
+trust CA-signed SMTP client certificates even when the EKU extension lists
+<b>serverAuth</b>, but does not list <b>clientAuth</b>. Such certificates are
+by default not accepted as valid TLS client certificates. When the certificate
+is trusted, its issuer and subject name are made available in SMTP policy
+service queries and the client connection will be reported "Trusted" in the
+logs. </p>
+
+<p> This feature is available in Postfix ≥ 3.12. </p>
diff --git a/src/tls/tls_server.c b/src/tls/tls_server.c
--- a/src/tls/tls_server.c
+++ b/src/tls/tls_server.c
@@ -387,2 +387,37 @@ static int ticket_cb(SSL *con, unsigned char name[],
unsigned char iv[],
+/* Accept use of TLS server-only certificates by TLS clients */
+
+static int trust_server_ccerts(X509_STORE_CTX *ctx, void *unused)
+{
+ const X509 *x;
+ EXTENDED_KEY_USAGE *xku;
+ int usages = 0;
+
+ if ((x = X509_STORE_CTX_get0_cert(ctx)) == NULL
+ || (xku = X509_get_ext_d2i(x, NID_ext_key_usage, NULL, NULL)) == NULL)
+ return X509_verify_cert(ctx);
+
+ for (int i = 0; i < sk_ASN1_OBJECT_num(xku); i++) {
+ switch (OBJ_obj2nid(sk_ASN1_OBJECT_value(xku, i))) {
+ case NID_server_auth:
+ usages |= XKU_SSL_SERVER;
+ break;
+ case NID_client_auth:
+ usages |= XKU_SSL_CLIENT;
+ break;
+ default:
+ break;
+ }
+ }
+ sk_ASN1_OBJECT_pop_free(xku, ASN1_OBJECT_free);
+
+ if (usages == XKU_SSL_SERVER) {
+ X509_VERIFY_PARAM *params = X509_STORE_CTX_get0_param(ctx);
+
+ X509_VERIFY_PARAM_set_purpose(params, X509_PURPOSE_SSL_SERVER);
+ X509_VERIFY_PARAM_set_trust(params, X509_TRUST_SSL_SERVER);
+ }
+ return X509_verify_cert(ctx);
+}
+
/* tls_server_init - initialize the server-side TLS engine */
@@ -752,2 +787,7 @@ TLS_APPL_STATE *tls_server_init(const TLS_SERVER_INIT_PROPS
*props)
+ if (props->ask_ccert && var_tls_srvr_ccerts) {
+ SSL_CTX_set_cert_verify_callback(server_ctx, trust_server_ccerts, NULL);
+ SSL_CTX_set_cert_verify_callback(sni_ctx, trust_server_ccerts, NULL);
+ }
+
/*
diff --git a/src/global/mail_params.h b/src/global/mail_params.h
--- a/src/global/mail_params.h
+++ b/src/global/mail_params.h
@@ -3569,2 +3569,10 @@ extern bool var_tls_fast_shutdown;
+ /*
+ * Whether to trust TLS client certificates whose extended key usage (EKU)
+ * lists only "serverAuth" and not "clientAuth".
+ */
+#define VAR_TLS_SRVR_CCERTS "tls_trust_server_ccerts"
+#define DEF_TLS_SRVR_CCERTS 0
+extern bool var_tls_srvr_ccerts;
+
/*
diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
--- a/src/tls/tls_misc.c
+++ b/src/tls/tls_misc.c
@@ -46,2 +46,3 @@
/* bool var_tls_fast_shutdown;
+/* bool var_tls_srvr_ccerts;
/*
@@ -315,2 +316,3 @@ bool var_tls_fast_shutdown;
bool var_tls_preempt_clist;
+bool var_tls_srvr_ccerts;
@@ -694,2 +696,3 @@ void tls_param_init(void)
VAR_TLS_FAST_SHUTDOWN, DEF_TLS_FAST_SHUTDOWN, &var_tls_fast_shutdown,
+ VAR_TLS_SRVR_CCERTS, DEF_TLS_SRVR_CCERTS, &var_tls_srvr_ccerts,
0,
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
