* Viktor Dukhovni via Postfix-users <postfix-users@postfix.org>: > 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.
Well spotted and that was the reason Postfix failed. We've added a SELinux policy to let tlsproxy do what it wants and things went back to normal. Also: As of today list.sys4.de offers and uses RSA *and* ECDSA certificates. TLSA RRs had been extended before we activated the new certs. > 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. Yes, list.sys4.de also uses TLS client certs and I'm not really sure I like you writing "typically without just cause". I'd rather have it the other way around and be irritated if clients do not identify themselves in TLS sessions as well. But then this leads to another discussion about mutual DANE-based identification where the client side need to identify itself to a DANE-verifying server as well. > 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. Why? I feel a little like I was feeling in the early 2000s when we had to justify offering STARTTLS on the server side. IMHO TLS should be default on both ends and any service not complying should need to explain why. > 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. You spotted the problem perfectly. It was tlsproxy being hindered by SELinux. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
