Re: Achieving trusted TLS connection

[Viktor Dukhovni]

> On Feb 1, 2018, at 1:44 PM, Danny Horne  wrote:
> 
> Possibly, do I understand right that I'm going to have to separate all
> cacerts from the bundle files before using rehash?

Yes, but if your OS distribution does not provide a package that handles
all this, perhaps you should just stick with:

tls_append_default_CA = no
smtpd_tls_CApath = /etc/pki/tls/certs

which will include the CA bundle, but in a way that won't also leak it
to each client as the list of preferred CAs, which you'd get with
explicitly setting smtpd_tls_CAfile.

The point is that the list of trusted CAs may change from time to time,
and you probably don't want to be stuck with stale copies...

Or just don't ask for client certs! Is it painful enough yet? :-)

-- 
Viktor.

Re: Achieving trusted TLS connection

[Danny Horne]

On 01/02/2018 6:40 pm, Viktor Dukhovni wrote:
>
>> On Feb 1, 2018, at 1:26 PM, Danny Horne  wrote:
>>
>> I might have a go at that later (can't find
>> c_rehash anywhere but do have csplit available)
>   https://www.openssl.org/docs/man1.1.0/apps/openssl-rehash.html
>   https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html
>
> Perhaps your O/S distribution left these to some package you did
> not yet install.
>
Possibly, do I understand right that I'm going to have to separate all
cacerts from the bundle files before using rehash?

Re: Achieving trusted TLS connection

[Viktor Dukhovni]

> On Feb 1, 2018, at 1:26 PM, Danny Horne  wrote:
> 
> I might have a go at that later (can't find
> c_rehash anywhere but do have csplit available)

  https://www.openssl.org/docs/man1.1.0/apps/openssl-rehash.html
  https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html

Perhaps your O/S distribution left these to some package you did
not yet install.

-- 
Viktor.

Re: Achieving trusted TLS connection

[Danny Horne]

On 01/02/2018 5:59 pm, Viktor Dukhovni wrote:
> This both loads the default CAfile and sets up the default CApath, so
> we don't yet know whether your CApath directory is fully prepared or
> not...  So now you could try reverting to:
>
>   tls_append_default_CA = no
>   smtpd_tls_CApath = /etc/pki/tls/certs
>
> which should work if the above directory has the expected symlinks.
> Otherwise, you could run "c_rehash" to make it so.  That'll save
> each smtpd(8) process the (probably small) cost of loading all the
> CAs at startup.
>
smtpd_tls_CApath is already set to that directory, and all files are
bundles, including many cacerts in the one file.  Bill Cole posted a
means of separating these, I might have a go at that later (can't find
c_rehash anywhere but do have csplit available)

Re: Achieving trusted TLS connection

[Viktor Dukhovni]

> On Feb 1, 2018, at 12:10 PM, Danny Horne  wrote:
> 
>> A simpler way to achieve the same goal would have been:
>>  http://www.postfix.org/postconf.5.html#tls_append_default_CA
>> 
>>  tls_append_default_CA = yes
>> 
>> bearing in mind the caution in the documentation, when enabling the
>> panoply of WebPKI trust-anchors (root CAs) DO NOT make the make the
>> mistake of also using "permit_tls_all_clientcerts", lest your server
>> become an open relay for every man and his dog who can get a Let's
>> Encrypt certificate...
>> 
> Ok, adding tls_append_default_CA = yes has finally given me trusted TLS
> connections, but I do wonder if it was worth it in the end!!
> 
> I am not using permit_tls_all_clientcerts

This both loads the default CAfile and sets up the default CApath, so
we don't yet know whether your CApath directory is fully prepared or
not...  So now you could try reverting to:

tls_append_default_CA = no
smtpd_tls_CApath = /etc/pki/tls/certs

which should work if the above directory has the expected symlinks.
Otherwise, you could run "c_rehash" to make it so.  That'll save
each smtpd(8) process the (probably small) cost of loading all the
CAs at startup.

-- 
Viktor.

Re: Achieving trusted TLS connection

[Bill Cole]

On 1 Feb 2018, at 11:46, Viktor Dukhovni wrote:

On Feb 1, 2018, at 11:43 AM, Bill Cole 
 wrote:


The "c_rehash" tool is an OpenSSL utility that generates symlinks in 
a directory full of certificate files such that each symlink name is 
derived from a cryptographic hash of the "Subject" of the certificate 
file to which it points. This is to support rapid identification of 
trusted certificates cited as the "Issuer" of a certificate being 
verified. If your OpenSSL is properly installed, you can get all the 
details from 'man c_rehash' and if not, you can see the man page for 
v1.0.2 at https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html.


Good clarification, thanks.  I just want to emphasize that
the "directory full of certificate files" needs to have one
certificate per file, as only the first certificate in each
file is processed by c_rehash.  There's not much point in
using CApath if all the certificates are in the same file,
so that's not supported.


Yes, that's an important point.

If one has a bundle of certs in one file, one can do something like this 
to split them into single-cert files (assuming you have GNU csplit):


csplit  -f ca-cert -b '.%03d.pem' curl-ca-bundle.crt '/END 
CERTIFICATE/+1' {*}

Re: Achieving trusted TLS connection

[Danny Horne]

On 01/02/2018 5:10 pm, Danny Horne wrote:
> Ok, adding tls_append_default_CA = yes has finally given me trusted TLS
> connections, but I do wonder if it was worth it in the end!!
>
> I am not using permit_tls_all_clientcerts
>
I forgot to add, thank you all for your help, though it might not have
actually 'fixed' anything, I've learnt something new today

Re: Achieving trusted TLS connection

[Danny Horne]

On 01/02/2018 4:56 pm, Viktor Dukhovni wrote:
> A simpler way to achieve the same goal would have been:
>   http://www.postfix.org/postconf.5.html#tls_append_default_CA
>
>   tls_append_default_CA = yes
>
> bearing in mind the caution in the documentation, when enabling the
> panoply of WebPKI trust-anchors (root CAs) DO NOT make the make the
> mistake of also using "permit_tls_all_clientcerts", lest your server
> become an open relay for every man and his dog who can get a Let's
> Encrypt certificate...
>
Ok, adding tls_append_default_CA = yes has finally given me trusted TLS
connections, but I do wonder if it was worth it in the end!!

I am not using permit_tls_all_clientcerts

Re: Achieving trusted TLS connection

[Viktor Dukhovni]

> On Feb 1, 2018, at 11:45 AM, Danny Horne  wrote:
> 
> # openssl version -d
> OPENSSLDIR: "/etc/pki/tls"
> 
> # ls -al /etc/pki/tls
> lrwxrwxrwx. 1 root root49 Nov 27 21:00 cert.pem -> 
> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
> drwxr-xr-x. 2 root root97 Dec 21 17:31 certs
> drwxr-xr-x. 2 root root 6 Nov  6 08:24 misc
> -rw-r--r--. 1 root root 10841 Nov  6 08:20 openssl.cnf

Here we see that /etc/pki/tls is not only reported by
"openssl version -d", but also has a "cert.pem" file,
a "certs" sub-directory, and an openssl.cnf file.

This matches the layout expected by OpenSSL.  Given this,
I'd expect to find the hashed symlinks in:

/etc/pki/tls/certs

Look there, and if all is as expected, your CApath would be:

  smtpd_tls_CApath = /etc/pki/tls/certs.

All this to get client certs to show as "Trusted", perhaps it
would have been easier to just not bother requesting client certs :-)

A simpler way to achieve the same goal would have been:

http://www.postfix.org/postconf.5.html#tls_append_default_CA

tls_append_default_CA = yes

bearing in mind the caution in the documentation, when enabling the
panoply of WebPKI trust-anchors (root CAs) DO NOT make the make the
mistake of also using "permit_tls_all_clientcerts", lest your server
become an open relay for every man and his dog who can get a Let's
Encrypt certificate...

-- 
Viktor.

Re: Achieving trusted TLS connection

[Viktor Dukhovni]

> On Feb 1, 2018, at 11:43 AM, Bill Cole 
>  wrote:
> 
> The "c_rehash" tool is an OpenSSL utility that generates symlinks in a 
> directory full of certificate files such that each symlink name is derived 
> from a cryptographic hash of the "Subject" of the certificate file to which 
> it points. This is to support rapid identification of trusted certificates 
> cited as the "Issuer" of a certificate being verified. If your OpenSSL is 
> properly installed, you can get all the details from 'man c_rehash' and if 
> not, you can see the man page for v1.0.2 at 
> https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html.

Good clarification, thanks.  I just want to emphasize that
the "directory full of certificate files" needs to have one
certificate per file, as only the first certificate in each
file is processed by c_rehash.  There's not much point in
using CApath if all the certificates are in the same file,
so that's not supported.

-- 
Viktor.

Re: Achieving trusted TLS connection

[Danny Horne]

Ok, didn't fully understand some of what you've said, so I'll just post
what I see (no hexadecimal symlinks found).  I've changed
smtpd_tls_CApath to /etc/pki/ca-trust/extracted/pem but that hasn't made
any difference

[root@indium tls]# openssl version -d
OPENSSLDIR: "/etc/pki/tls"
[root@indium tls]#
[root@indium tls]# ls -al /etc/pki/tls
total 12
drwxr-xr-x. 5 root root    81 Jan 24 16:41 .
drwxr-xr-x. 9 root root   103 Jan 26 20:18 ..
lrwxrwxrwx. 1 root root    49 Nov 27 21:00 cert.pem ->
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
drwxr-xr-x. 2 root root    97 Dec 21 17:31 certs
drwxr-xr-x. 2 root root 6 Nov  6 08:24 misc
-rw-r--r--. 1 root root 10841 Nov  6 08:20 openssl.cnf
drwxr-xr-x. 2 root root    60 Dec 21 17:32 private
[root@indium tls]#
[root@indium tls]# ls -al /etc/pki/ca-trust/extracted/pem
total 396
drwxr-xr-x. 2 root root    101 Dec 18 15:19 .
drwxr-xr-x. 5 root root 58 Dec 18 15:19 ..
-r--r--r--. 1 root root 179176 Dec 18 15:19 email-ca-bundle.pem
-r--r--r--. 1 root root  0 Dec 18 15:19 objsign-ca-bundle.pem
-rw-r--r--. 1 root root    898 Nov 27 20:58 README
-r--r--r--. 1 root root 219895 Dec 18 15:19 tls-ca-bundle.pem

Re: Achieving trusted TLS connection

[Bill Cole]

On 1 Feb 2018, at 10:44, Danny Horne wrote:


I've changed smtpd_tls_CApath back to pointing at the directory.  Not
sure what you mean by "hashed" via "c_rehash"


The "c_rehash" tool is an OpenSSL utility that generates symlinks in a 
directory full of certificate files such that each symlink name is 
derived from a cryptographic hash of the "Subject" of the certificate 
file to which it points. This is to support rapid identification of 
trusted certificates cited as the "Issuer" of a certificate being 
verified. If your OpenSSL is properly installed, you can get all the 
details from 'man c_rehash' and if not, you can see the man page for 
v1.0.2 at https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html.

Re: Achieving trusted TLS connection

[Viktor Dukhovni]

> On Feb 1, 2018, at 10:44 AM, Danny Horne  wrote:
> 
>> You report settings of:
>>  smtpd_tls_CApath = /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
>>  smtpd_tls_ask_ccert = yes
>>  smtpd_tls_ccert_verifydepth = 2
>> 
>> Surely "ca-bundle.trust.crt" is a file not a directory.  This would work as
>> a "CAfile", but I very much recommend that you use CApath instead.  Point
>> your CApath at the directory with all the certs, that "hashed" via
>> "c_rehash" or similar.  If running smtpd(8) chrooted, make sure there's
>> a copy of the CApath directory inside the jail.
> 
> I've changed smtpd_tls_CApath back to pointing at the directory.  Not
> sure what you mean by "hashed" via "c_rehash"

Well, that's the critical part of using CApath, the directory needs to
contain a separate file for each trusted CA certificate and also be
"hashed" (indexed if you like) by the OpenSSL c_rehash program or
equivalent.  Some OS distributions do this for you automatically, as
part of updating the package that delivers the CA bundle.

You can tell when this is done because the directory will contain a
bunch of hexadecimal symlinks ending in .0 and increasingly less
frequently also .1, .2, ...  For example:

cd8c0d63.0 -> fnmt-rcm.pem

In your case the hashed directory could any of:

   /etc/pki/ca-trust/extracted/openssl/
   /etc/pki/ca-trust/extracted
   /etc/pki/ca-trust
   /etc/pki

or even some other directory that uses the above as raw sources to make
links to.  If the OpenSSL library on your system is built to expect to
find certificates in the same place where they are delivered by the
certificate bundle package, then you can run:

  openssl version -d 

which outputs something like:

   $ openssl version -d
   OPENSSLDIR: "/etc/ssl"

from which you can deduce that the built-in CAfile and CApath are:

CAfile: /etc/ssl/cert.pem
CApath: /etc/ssl/certs/

Adjust accordingly and look for lots of hexadecimal symlinks to
various .pem files.

>> Is "SwissSign Silver CA - G2" included in your "ca bundle"?
>> 
> Yes it is.  Is it possible that Postfix can't read that file for some
> reason?

Strictly speaking, that'd be the OpenSSL library, called by the Postfix
smtpd(8) server.  And that problem could happen if you're running it
from a chroot jail, but first figure out whether you have a suitably
prepared CApath directory anywhere...

-- 
Viktor.

Re: Achieving trusted TLS connection

[Danny Horne]

On 31/01/2018 8:31 pm, Viktor Dukhovni wrote:
> You report settings of:
>   smtpd_tls_CApath = /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
>   smtpd_tls_ask_ccert = yes
>   smtpd_tls_ccert_verifydepth = 2
>
> Surely "ca-bundle.trust.crt" is a file not a directory.  This would work as
> a "CAfile", but I very much recommend that you use CApath instead.  Point
> your CApath at the directory with all the certs, that "hashed" via
> "c_rehash" or similar.  If running smtpd(8) chrooted, make sure there's
> a copy of the CApath directory inside the jail.

I've changed smtpd_tls_CApath back to pointing at the directory.  Not
sure what you mean by "hashed" via "c_rehash"
>
> Is "SwissSign Silver CA - G2" included in your "ca bundle"?
>
Yes it is.  Is it possible that Postfix can't read that file for some
reason?

Re: Achieving trusted TLS connection

[Viktor Dukhovni]

> On Jan 31, 2018, at 4:12 PM, Bastian Blank 
>  wrote:
> 
> On Wed, Jan 31, 2018 at 03:31:08PM -0500, Viktor Dukhovni wrote:
>> Is "SwissSign Silver CA - G2" included in your "ca bundle"?
> 
> Also, is this server known to provide a client cert?

If it had not, the log message would have said "Anonymous", rather than 
"Untrusted".

-- 
Viktor.

Re: Achieving trusted TLS connection

[Danny Horne]

On 31/01/2018 9:12 pm, Bastian Blank wrote:
> On Wed, Jan 31, 2018 at 03:31:08PM -0500, Viktor Dukhovni wrote:
>> Is "SwissSign Silver CA - G2" included in your "ca bundle"?
> Also, is this server known to provide a client cert?
>
> Bastian
>
Not sure about 'provide', but the following shows it does use a
certificate included in my CA file

openssl s_client -showcerts -starttls smtp -connect mx1.mailbox.org:25

Re: Achieving trusted TLS connection

[Bastian Blank]

On Wed, Jan 31, 2018 at 03:31:08PM -0500, Viktor Dukhovni wrote:
> Is "SwissSign Silver CA - G2" included in your "ca bundle"?

Also, is this server known to provide a client cert?

Bastian

-- 
There's another way to survive.  Mutual trust -- and help.
-- Kirk, "Day of the Dove", stardate unknown

Re: Achieving trusted TLS connection

[Viktor Dukhovni]

> On Jan 31, 2018, at 2:46 PM, Danny Horne  wrote:
> 
> I didn't think achieving an inbound trusted TLS connection required
> DANE, merely a trusted certificate (which was verifiable through my
> trusted CA file.
> 
> Maybe I misunderstood the documentation.

I see, sorry, I thought you were looking for DANE auth.  For
"trusted" client connections you'll need a suitable CApath
that includes the relevant trust-anchors and any intermediate
CAs that the sending client might have left out in error.

You report settings of:

  smtpd_tls_CApath = /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
  smtpd_tls_ask_ccert = yes
  smtpd_tls_ccert_verifydepth = 2

Surely "ca-bundle.trust.crt" is a file not a directory.  This would work as
a "CAfile", but I very much recommend that you use CApath instead.  Point
your CApath at the directory with all the certs, that "hashed" via
"c_rehash" or similar.  If running smtpd(8) chrooted, make sure there's
a copy of the CApath directory inside the jail.

When mx1.mailbox.org is the receiving MTA, its certificate chain is:

  mx1.mailbox.org[80.241.60.212]: pass: TLSA match: depth = 0, name = 
*.mailbox.org
TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384
name = *.mailbox.org
name = mailbox.org
depth = 0
  Issuer CommonName = SwissSign Server Silver CA 2014 - G22
  Issuer Organization = SwissSign AG
  notBefore = 2014-12-04T12:05:04Z
  notAfter = 2019-12-04T12:05:04Z
  Subject CommonName = *.mailbox.org
  pkey sha256 [matched] <- 3 1 1 
4758af6f02dfb5dc8795fa402e77a8a0486af5e85d2ca60c294476aadc40b220
depth = 1
  Issuer CommonName = SwissSign Silver CA - G2
  Issuer Organization = SwissSign AG
  notBefore = 2014-09-19T20:36:43Z
  notAfter = 2029-09-15T20:36:43Z
  Subject CommonName = SwissSign Server Silver CA 2014 - G22
  Subject Organization = SwissSign AG
  pkey sha256 [nomatch] <- 2 1 1 
989c1c480d561396df0ac439a3bf70182bdab2fc1d56cce7665a91d47dd83dd2
depth = 2
  Issuer CommonName = SwissSign Silver CA - G2
  Issuer Organization = SwissSign AG
  notBefore = 2006-10-25T08:32:46Z
  notAfter = 2036-10-25T08:32:46Z
  Subject CommonName = SwissSign Silver CA - G2
  Subject Organization = SwissSign AG
  pkey sha256 [nomatch] <- 2 1 1 
9318226f8c83afe47f5f47c24f59ce12dba8c73b181bee6b2ea1f40a06bc1869


Is "SwissSign Silver CA - G2" included in your "ca bundle"?

-- 
Viktor.

Re: Achieving trusted TLS connection

[Danny Horne]

Thanks for the reply,

I didn't think achieving an inbound trusted TLS connection required
DANE, merely a trusted certificate (which was verifiable through my
trusted CA file.

Maybe I misunderstood the documentation

Re: Achieving trusted TLS connection

[Viktor Dukhovni]

> On Jan 31, 2018, at 1:14 PM, Danny Horne  wrote:
> 
> I've read what Postfix documentation I can find on the subject, and I
> don't understand why I'm seeing untrusted connections rather than
> trusted.  I'm using an account at mailbox.org for testing purposes, they
> use DNSSEC / DANE for there server (as do I), and I see a verified
> connection when sending email to their server, but returned connections
> are untrusted.
> 
> This is what's logged when TLS logging is set to 2 -

TLS log level 1 is almost always enough.  More logging generally just
makes it harder to see the key information amidst all the low-level
noise.

> Jan 31 17:53:31 indium postfix/smtpd[30307]: Untrusted TLS connection
> established from mx1.mailbox.org[80.241.60.212]: TLSv1.2 with cipher
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

It is exactly what's expected. DANE TLS is used by clients to authenticate
servers.  There is no standard (I did not make progress on the draft
quickly enough) to use DANE to authenticate TLS clients to servers.

The server would need to know when and where to search for the client's
TLSA records.  This would perhaps require a new SMTP command so that the
server configures its TLS engine to ask for client certificates and would
look up the client's TLSA records at something like:

_smtp-client. IN TLSA ?

or a just-in-time TLS extension in the client TLS HELLO, that would
cause the server to do the same via a suitable TLS extension callback.

Even if this were all done, what would you do differently with clients
that did authenticate their HELO name (or some name sent in the TLS
extension)?

If there is a sufficiently well-motivated use-case for using DANE for
TLS client auth, I could resume work with Shumon Huque on the DANE
client auth draft, and add support for this in Postfix and OpenSSL,
but presently this does not seem a high priority.  It is not clear
what real benefit such client authentication would bring.

Perhaps once DANE authentication of servers is more common, we can
look at extending DANE to cover clients, but for now the first step
is convincing enough servers to publish TLSA records.

Presently, I am tracking 5.2 million DNSSEC domains of which 177
thousand have TLSA records for at least all their primary MX hosts,
with 176 thousand of those having TLSA records for all MX hosts.

While we have some good progress with early adopters, we still
have a long way to go.  I'll be giving a talk on DANE adoption
at ICANN61 in March.

-- 
Viktor.

Achieving trusted TLS connection

[Danny Horne]

Hi all,

I've read what Postfix documentation I can find on the subject, and I
don't understand why I'm seeing untrusted connections rather than
trusted.  I'm using an account at mailbox.org for testing purposes, they
use DNSSEC / DANE for there server (as do I), and I see a verified
connection when sending email to their server, but returned connections
are untrusted.

This is what's logged when TLS logging is set to 2 -

Jan 31 17:53:31 indium postfix/smtpd[30307]: setting up TLS connection
from mx1.mailbox.org[80.241.60.212]
Jan 31 17:53:31 indium postfix/smtpd[30307]:
mx1.mailbox.org[80.241.60.212]: TLS cipher list
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH:!aNULL"
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
client hello
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
server hello
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
certificate
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
key exchange
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
certificate request
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
server done
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
server done
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
client certificate
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
client key exchange
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
certificate verify
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
change cipher spec
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
finished
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
session ticket
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
change cipher spec
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
finished
Jan 31 17:53:31 indium postfix/smtpd[30307]: Untrusted TLS connection
established from mx1.mailbox.org[80.241.60.212]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

This is the relevant part of main.cf -

smtpd_use_tls = yes
smtpd_tls_key_file  = /etc/pki/tls/private/mail.trisect.uk.key
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.trisect.uk.crt
smtpd_tls_CApath = /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_ccert_verifydepth = 2
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_auth_only = no
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s

As far as I can tell the CA certificate used by mailbox.org is included
in ca-bundle.trust.crt

What have I missed (if anything)?

Thanks for looking