From looking at the GnuTLS source I'm not able to guess what state it's
missing. It's unfortunate that it follows a null pointer rather than
checking and returning an error from the gnutls_certificate_verify_peers2 API
call; I'd call that a bug in GnuTLS.
It's interesting that we had a good TLS conn for the first MX tried, in the
same process. Presumably that leaves GnuTLS in some awkward state. If the
preload support Andreas identified is also relevant to this variant then
the "client CA bundle" is suspect. We're relying on the bundle loaded
during the parent Exim startup (either daemon or cmdline-send), rather than
(as before that commit) loading it afresh for every TLS connection.
A workaround would be to introduce a '$' into the transport
tls_verify_certificates option. "${expand:}" would suffice, added to the
existing; this is just to make exim think the option value might vary so must
not be cached.
I'd suggest raising a bug against GnuTLS for this.
Testing with a range of different GnuTLS versions might also be useful.
This one is different to Andreas'; the crash is during the verify stage of
TLS establishment. The stacktrace is:
_gnutls_ trust_list_ get_issuer x509_trust_ list_get_ issuer x509_trust_ list_verify_ crt2 x509_cert_ verify_ peers certificate_ verify_ peers ^^^ certificate_ verify_ peers2 ^^^ GnuTLS library
gnutls_
gnutls_
_gnutls_
gnutls_
gnutls_
verify_certificate vvv Exim
tls_client_start vvv
smtp_setup_conn
From looking at the GnuTLS source I'm not able to guess what state it's certificate_ verify_ peers2 API
missing. It's unfortunate that it follows a null pointer rather than
checking and returning an error from the gnutls_
call; I'd call that a bug in GnuTLS.
It's interesting that we had a good TLS conn for the first MX tried, in the
same process. Presumably that leaves GnuTLS in some awkward state. If the
preload support Andreas identified is also relevant to this variant then
the "client CA bundle" is suspect. We're relying on the bundle loaded
during the parent Exim startup (either daemon or cmdline-send), rather than
(as before that commit) loading it afresh for every TLS connection.
A workaround would be to introduce a '$' into the transport certificates option. "${expand:}" would suffice, added to the
tls_verify_
existing; this is just to make exim think the option value might vary so must
not be cached.
I'd suggest raising a bug against GnuTLS for this.
Testing with a range of different GnuTLS versions might also be useful.