On 07/07/2024 14:31, Viktor Dukhovni via Exim-users wrote:
> So is sure seems like Exim DANE with GnuTLS fails to set the TLSA base
> domain as the SNI name, while the Exim with OpenSSL does take care of
> that...
I assume you're inferring that from a test of poking that site with/without
an SNI, independent of Exim use?
Meantime, hunting through the Exim project regression testsuite, this (SNI sending)
is tested by case 5802, subcase "t1@???". The SNI received by
the server end of the connection is logged, and the log compared against a golden
file for the testcase.
Both OpenSSL and GnuTLS pass, silently, this testcase on my laptop.
I infer that the SNI is indeed sent over the connection (I've not gone
as far as a packet capture). The GnuTLS version here is 3.8.5
A test run on a Debian 12 system - with GnuTLS 3.7.9 - also passes.
I've been assuming all along that the OP's Exim is in fact configured to
use DANE for this connection. Have we in fact verified this (yet another
item which would be obvious given debug...)?
[ Check this with "exim -bP transport remote_smtp | grep dane"
replacing "remote_smtp" with the name of the transport being used.
The project defaults have hosts_try_dane = *
but this could be modified either by the distro or the sysadmin.
]
Barring such a config error, the only other thing that comes to mind is an
MITM (errrm, "security proxy") which happens to strip SNI. But that also seems
unlikely.
--
Cheers,
Jeremy
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
