https://bugs.exim.org/show_bug.cgi?id=2886
--- Comment #25 from Jeremy Harris <jgh146...@wizmail.org> --- This one is different to Andreas'; the crash is during the verify stage of TLS establishment. The stacktrace is: _gnutls_trust_list_get_issuer gnutls_x509_trust_list_get_issuer gnutls_x509_trust_list_verify_crt2 _gnutls_x509_cert_verify_peers gnutls_certificate_verify_peers ^^^ gnutls_certificate_verify_peers2 ^^^ GnuTLS library 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 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. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##