Understanding master.cf

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Understanding master.cf

Gerben Wierda
I’m setting up a new postfix based on sources (via MacPorts) and master has this configuration snippet:

smtp      inet  n       -       y       -       1       postscreen
smtpd     pass  -       -       y       -       -       smtpd
  -o receive_override_options=no_address_mappings
dnsblog   unix  -       -       n       -       0       dnsblog
tlsproxy  unix  -       -       n       -       0       tlsproxy

My certificates live outside the chroot jail, but I expected tlsproxy to handle it (and it is not chrooted). Instead, my log says:

Oct 05 11:35:21 mail postfix/smtpd[2218]: cannot load Certification Authority data, CAfile="/etc/certificates/www.rna.nl.F1BCD75E0F6DD3B3B0145CB328699BDEEF21FA5C.chain.pem": disabling TLS support

Does chrooting smtpd require a local copy of certificates inside the chroot jail? Or can this be ignored because I use postscreen to handle port 25? But then, why does my log say:

Oct 05 11:41:50 mail postfix/smtpd[2338]: connect from unknown[192.168.2.67]

instead of

Oct 05 11:41:50 mail postscreen[2338]: connect from unknown[192.168.2.67]

if I connect to port 25 from another machine? How do I know I’m connected to postscreen, not to smtpd?

(Note, syslog is completely broken on macOS, so I depend on logging to mail log files). I’m running postfix 3.4.6.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding master.cf

Wietse Venema
postscreen(8) is NOT a proxy. It passes the file descriptor to an
smtpd(8) process, if the client is whitelisted. Therefore, smtpd(8)
TLS configuration is the same whether you use postscreen or not.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Understanding master.cf

Viktor Dukhovni
In reply to this post by Gerben Wierda
On Sat, Oct 05, 2019 at 11:51:24AM +0200, Gerben Wierda wrote:

> [...], my log says:
>
> Oct 05 11:35:21 mail postfix/smtpd[2218]: cannot load Certification
>   Authority data, CAfile="/etc/certificates/www.rna.nl.F1BCD75E0F6DD3B3B0145CB328699BDEEF21FA5C.chain.pem":
>   disabling TLS support

Are you sure this is a CAfile (containing certificates of root CAs,
a.k.a. trust anchors)?  Based on the name, I would have guessed
this to be a certificate chain file for the server's own certificate,
possibly also including the server's private key?

Please post the output of (and/or errors reported by):

  # chain=/etc/certificates/www.rna.nl.F1BCD75E0F6DD3B3B0145CB328699BDEEF21FA5C.chain.pem
  # egrep '^----- ' "$chain"
  # openssl crl2pkcs7 -nocrl -certfile "$chain" |
        openssl pkcs7 -print_certs -noout -text |
        egrep '(Certificate|Subject|Issuer):'

this should show the types of PEM objects stored in that file, without
disclosing any sensitive content.

> Does chrooting smtpd require a local copy of certificates inside the chroot
> jail?

No.  The SMTP server loads its CAfile before entering the chroot
jail (while still running as root).  There must be something wrong
with that file, but you've elided the logging of the error:

        if (CAfile || CApath) {
            if (!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) {
                msg_info("cannot load Certification Authority data, "
                         CA_PATH_FMT CA_PATH_FMT ": disabling TLS support",
                         CA_PATH_ARGS(CAfile, CApath),
                         CA_PATH_ARGS(CApath, 0));
                tls_print_errors();
                return (-1);
            }
            ...
        }

The tls_print_errors() function logs the actual reason as reported
by the OpenSSL library.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding master.cf

Gerben Wierda
On 5 Oct 2019, at 18:43, Viktor Dukhovni <[hidden email]> wrote:

Thank you. That helped (more to point out I had made a stupid mistake).

On Sat, Oct 05, 2019 at 11:51:24AM +0200, Gerben Wierda wrote:

[...], my log says:

Oct 05 11:35:21 mail postfix/smtpd[2218]: cannot load Certification
 Authority data, CAfile="/etc/certificates/www.rna.nl.F1BCD75E0F6DD3B3B0145CB328699BDEEF21FA5C.chain.pem":
 disabling TLS support

Are you sure this is a CAfile (containing certificates of root CAs,
a.k.a. trust anchors)?  Based on the name, I would have guessed
this to be a certificate chain file for the server's own certificate,
possibly also including the server's private key?

Yes, it works with postfix when it can be read. It is a full letsencrypt chain. 

It turns out I forgot that I had decided not to install in /etc/certificates (where macOS Server maintains certificates)


Please post the output of (and/or errors reported by):

 # chain=/etc/certificates/www.rna.nl.F1BCD75E0F6DD3B3B0145CB328699BDEEF21FA5C.chain.pem
 # egrep '^----- ' "$chain"
 # openssl crl2pkcs7 -nocrl -certfile "$chain" |
       openssl pkcs7 -print_certs -noout -text |
       egrep '(Certificate|Subject|Issuer):'

this should show the types of PEM objects stored in that file, without
disclosing any sensitive content.

On the system I copied it from:

dumbledore:postfix gerben$ openssl crl2pkcs7 -nocrl -certfile /etc/certificates/www.rna.nl.F1BCD75E0F6DD3B3B0145CB328699BDEEF21FA5C.chain.pem | openssl pkcs7 -print_certs -noout -text | egrep '(Certificate|Subject|Issuer):'
Certificate:
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Subject: CN=www.rna.nl
Certificate:
        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Certificate:
        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Subject: O=Digital Signature Trust Co., CN=DST Root CA X3

But on the new system I was testing I had indeed made an error, because it no longer lives in /etc/certificates (where macOS Server maintains everything) but only in /etc/letsencrypt. There I got cert, chain and full chain and while the chain that macOS Server creates has all of them, the letsencrypt ones are separate:

bash-3.2#  openssl crl2pkcs7 -nocrl -certfile /etc/letsencrypt/live/www.rna.nl/cert.pem | openssl pkcs7 -print_certs -noout -text | egrep '(Certificate|Subject|Issuer):'
Certificate:
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Subject: CN=www.rna.nl
bash-3.2# openssl crl2pkcs7 -nocrl -certfile /etc/letsencrypt/live/www.rna.nl/chain.pem | openssl pkcs7 -print_certs -noout -text | egrep '(Certificate|Subject|Issuer):'
Certificate:
        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
bash-3.2# openssl crl2pkcs7 -nocrl -certfile /etc/letsencrypt/live/www.rna.nl/fullchain.pem | openssl pkcs7 -print_certs -noout -text | egrep '(Certificate|Subject|Issuer):'
Certificate:
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Subject: CN=www.rna.nl
Certificate:
        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3

Does chrooting smtpd require a local copy of certificates inside the chroot
jail?

No.  The SMTP server loads its CAfile before entering the chroot
jail (while still running as root).  There must be something wrong
with that file,

Indeed. It just wasn’t there. I need to make sure the _postfix user can read the files. Normally, _postscript cannot read /etc/letsencrypt/live so I’ll have to figure a way around that that doesn’t break on every future ech-90-days letsencrypt update. Probably easiest is to give the postfix user read access to /etc/letsencrypt/live/www.rna.nl and it’s content. Otherwise it is a deplyhook in letsencrypt.

But for now, I can copy and go on with testing.

G
Reply | Threaded
Open this post in threaded view
|

Re: Understanding master.cf

Viktor Dukhovni
On Sun, Oct 06, 2019 at 12:18:05PM +0200, Gerben Wierda wrote:

> Yes, it works with postfix when it can be read. It is a full letsencrypt chain.

I am puzzled as to why you're trying to set this as your "CAfile".
It is not a file containing trust anchors (root CAs).  And, unless
your SMTP server solicits client certificates, your smtpd(8) does
not need a CAfile at all.

Seems you're confusing "smtpd_tls_cert_file" with "smtpd_tls_CAfile".

> bash-3.2# openssl crl2pkcs7 -nocrl -certfile /etc/letsencrypt/live/www.rna.nl/fullchain.pem | [...]
> Certificate:
>         Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
>         Subject: CN=www.rna.nl
> Certificate:
>         Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
>         Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3

The "fullchain.pem" file is the one and *only* correct file to set
as your "smtpd_tls_cert_file".  You do not generally need an
"smtpd_tls_CAfile".  Your certificate will fail to verify in many
cases if you fail to include the intermediate CA cert(s) in the
fullchain.pem file.

> > No.  The SMTP server loads its CAfile before entering the chroot
> > jail (while still running as root).  There must be something wrong
> > with that file,
>
> Indeed. It just wasn’t there. I need to make sure the _postfix user can
> read the files.

Actually, you don't.  The "smtpd_tls_cert_file" is loaded while
Postfix is running as root.

--
        Viktor.