On Tue, Nov 14, 2023 at 03:56:25PM +0100, Patrick Ben Koetter via Postfix-users
wrote:
> It turned out that RedHat's SELinux policy does not cover Postfix' tlsproxy
> and whenever tlsproxy takes out to do what Postfix wants it to do SELinux will
> interfere and prohibit it from doing that. That in consequence made the SMTP
> service throttle and so it came to a stillstand.
In particular, presumably read access to the client cert .pem files was
blocked, though perhaps access to other essential resources was also
denied.
> For the moment we decided to do without TLS session caching in Postfix
> smtp-client *and* sending client side x509 certificates on demand in
> favor of running a more secure platform.
I am having some trouble parsing the above. I think you're saying
you're keeping SELinux enabled ("more secure platform"), and going
without client certs *and* without TLS connection reuse.
My vague impression from upthread was that disabling client certs was
sufficient, and connection reuse would then work? Was that not the
case?
> Our long-term goal is to re-enable the Postfix features *and* use
> SELinux. (RedHat if you're on this list and following this thread
> ping me offlist and I'll be happy to share all information we can
> provide.)
My recommendation of not gratuitously enabling client certs stands, they
add no value when (almost always) the server can't use them in any
meaningful way.
Client certificates are for prior bilateral security arrangements
with *specific* servers that know what to do with specific client
certificates.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
