Many thanks, Viktor and Gerald, for demonstrating my first stated problem: There seems to be no consensus about how to configure servers and services.
Gerald's information seems to be referencing older Postfix versions and "legacy" parameters, as Viktor pointed out. You both missed a detail I found on http://www.postfix.org/postconf.5.html#smtpd_tls_chain_files and I think you again for mentioning this which prompted me to revisit, reread, and re-understand this parameter. The Detail: Each chain file has two or three pieces - private_keyN, certificateN, [chainN] The only place I found this "demonstrated" was under http://www.postfix.org/postconf.5.html#smtp_tls_cert_file which is obsoleted in favor of smtp_tls_chain_files # umask 077 # cat client_key.pem client_cert.pem intermediate_CA.pem > chain.pem This clarification may be enough to get everything moving again. We shall see. -----Original Message----- From: <owner-postfix-us...@postfix.org> on behalf of Viktor Dukhovni <postfix-us...@dukhovni.org> Reply-To: "postfix-users@postfix.org" <postfix-users@postfix.org> Date: Tuesday, June 29, 2021 at 19:52 To: "postfix-users@postfix.org" <postfix-users@postfix.org> Subject: [EXTERNAL] Re: Training and/or Consluting ? On Tue, Jun 29, 2021 at 11:59:49PM +0200, Gerald Galster wrote: > > Do you concatenate the server certificate, key, and CA cert chain > > (and in what order) or do you leave them separate ? > > smtpd_use_tls = yes This is obsolete. The non-obsolete syntax is: smtpd_tls_security_level = may > smtpd_tls_key_file = /etc/letsencrypt/live/mx1.mailserver.com/privkey.pem With a sufficiently recent version of Postfix, one can also use: http://www.postfix.org/postconf.5.html#smtpd_tls_chain_files with Let's encrypt this would look like: smtpd_tls_chain_files = # Each key must precede the chain file, or be the first PEM # object in the same file as the certificate chain. The EE # (end-entity) (server) certificate must precede the issuing # CA(s). # /etc/letsencrypt/live/mx1.mailserver.com/privkey.pem, /etc/letsencrypt/live/mx1.mailserver.com/fullchain.pem > smtpd_tls_CAfile = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem > > - this is used when postfix needs to verify connections to other hosts No, that's would be what 'smtp_tls_CAfile' is for, the "smtpd" version is for verifying incoming *client* certificates, which is not widely used. But even 'smtp_tls_CAfile' is only useful if one is actually authenticating some remote destinations, not just doing opportunistic unauthenticated TLS. Otherwise, no CAfile is needed in either direction. > # Postfix smtp-auth > unix_listener /var/spool/postfix/private/auth { > mode = 0666 > } I have somewhat tighter permissions: service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } > broken_sasl_auth_clients = yes > smtpd_sasl_security_options = noanonymous With authentication enabled only for TLS, there's no need to allow plaintext auth when TLS is absent. Best to leave that parameter alone. Also leave "smtpd_sasl_auth_enable = no" by default, and only enable it via master.cf for the submission services. > for incoming connections: > smtpd_tls_security_level = may Correct this time. > for outgoing connections: > smtp_tls_security_level = may Or perhaps "dane", if you have a local validating resolver, with just "127.0.0.1" and/or "::1" in /etc/resolv.conf and also set: smtp_dns_support_level = dnssec -- Viktor.
