Hello Victor, thanks for the insights. Based on my experience, the mail domain is almost never in the SANs of a certificate, not even with self-hosted domains like mine. In other words, secure is likely to cause a lot more manual configuration than verify. I´d definitely appreciate if mail.cloud9.net could update their configuration as then I could get rid of some exceptions, and others would not have to think about it when moving forward w.r.t. security. Thanks, Joachim
-----Ursprüngliche Nachricht----- Von: owner-postfix-us...@postfix.org <owner-postfix-us...@postfix.org> Im Auftrag von Viktor Dukhovni Gesendet: Monday, 10 January 2022 00:01 An: postfix-users@postfix.org Betreff: Re: TLS enforcement options? On Sun, Jan 09, 2022 at 10:22:36PM +0100, Joachim Lindenberg wrote: > I configured my Email server (actually a mailcow-dockerized which in > turn uses postfix) to enforce TLS for outbound mail. Obviously that > will fail occasionally, but I also have a daemon watching the postfix > queue and alerting me. Kind of works for me. Ok, while subscribing to > this mailing list I had to add two more exceptions, because this > mailing list uses an untrusted certificate > (https://www.checktls.com/TestReceiver?LEVEL=DETAIL > <https://www.checktls.com/TestReceiver?LEVEL=DETAIL&EMAIL=majordom > o...@postfix.org> &EMAIL=majord...@postfix.org). Aren´t letsencrypt > certs cheap enough in order to get rid of untrusted certificates? The certificate is fine, the actual problem is that mail.cloud9.net does not include the intermediate issuer certificate in its certificate chain, which consists of justs the leaf certificate. The issuer cert for "Sectigo RSA Domain Validation Secure Server CA" would be needed to complete the chain to a WebPKI trust anchor (root CA). Sectigo sure go to a lot of trouble to make obtaining the intermediate certificate a laborious process, I am attaching a copy, along with a "just in case" cross-cert for its issuer. > When reading the documentation page > http://www.postfix.org/TLS_README.html#client_tls however I am > wondering what the difference between options “verify” and “secure” > is. By default, "verify" checks whether the presented certificate matches the MX hostname, which is typically obtained via unauthenticated DNS lookups, so easily subject to active (MiTM) attacks. With "secure" the presented certificate is checked agains the nexthop domain (typically the domain part of the recipient address). This is not subject to attacks via forged DNS replies. However, typically the MX host certificate will not have the recipient domain as one of its SANs unless the domain is self-hosted. For example, "postfix.org" does not appear in the certificate of "mail.cloud9.net". So "secure" is often not an option, unless you specify explicit non-default matching criteria, at which point the difference between "secure" and "verify" vanishes, they only differ in the default name matching patterns. > I read it several times and got the message, I should not use either, > but what exactly is the difference remained unclear to me. Is “DNS > forgery resistant server certificate verification“ defined in some RFC > or other document I am not aware of? It is defined (explained) in TLS_README. Sorry it was not as clear as you would like. -- Viktor.
