On Sun, Sep 17, 2023 at 06:20:53PM +0200, Patrick Ben Koetter via Postfix-users
wrote:
> Yesterday we upgraded LE certs and it seems – we haven't had time to
> investigate in that yet – SELinux bite Postfix where it shouldn't.
> Astonishingly SELinux has been running like that for 193 days and the problem
> should have occurred long time before we exchanged the LE cert. But all of
> what I'm writing is rumor and none has been proven. I'll write more when we
> have proven what went wrong.
Do you have SMTP client TLS connection reuse enabled? If so, TLS
connections are made via tlsproxy(8), with the smtp(8) client unaware of
any initialisation issues until STARTTLS.
If you also have TLS client certs configured (typically without just
cause) to be sent to servers that happen to request them (also typically
without just cause), then a failure to load the client certs breaks TLS
support in tlsproxy(8), which makes all attempts at "STARTTLS" fail.
We could perhaps consider soft-failing failure to load certificates in
the SMTP client (tls_client_init()). But this requires care, because
mail could bounce when the server is a submission relay that optionally
authenticates the client via its X.509 certificate, but doesn't
terminate the handshake when a client certificate is not presented
(perhaps it also supports SASL as an alternative).
The best solution is configure client certs *sparingly*, only for
transports dedicated to destinations that definitely need the client
certs, and not otherwise.
It is not possible to make an educated guess as to why tlsproxy(8) may
not have been able to load the certs, if that's what happened, without
some additional context from the server.
Of course the problem could be entirely unrelated to tlsproxy(8), but
there are fewer obvious opportunities for late failure when TLS is
used directly by the smtp(8) client.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
