> On 5 Oct 2019, at 18:43, Viktor Dukhovni <postfix-us...@dukhovni.org> 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 <http://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 <http://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
