Hello Viktor, thanks for your valuable assistance.
>Author: Viktor Dukhovni via Exim-users >Date: 2024-07-08 04:30 +200 >To: exim-users >Old-Topics: [exim] Re: Follow-Up: Debug TLS/DANE problems it is GnuTLS!, >[exim] Re: Follow-Up: Debug TLS/DANE problems it is GnuTLS!, [exim] Re: >Problems with outgoing DANE-TLSA, when CA-anchored test fails, [exim] no SNI >used, when sending TLS secured messages out >Subject: [exim] Re: Debug TLS/DANE problems >Perhaps the issue is as mundane as you not having a local validating >resolver in /etc/resolv.conf, so that the destination domain looks >unsigned to Exim? Can you post the output of: > $ dig +noall +stats +comment -t mx et.lindenberg.one | grep -E '^;; > (flags|SERVER):' >On my system, I see: > $ dig +noall +stats +comment -t mx et.lindenberg.one | grep -E '^;; > (flags|SERVER):' > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) >Note the "ad" bit in the response *flags*, and "127.0.0.1" for the >*SERVER*. I have a validating local resolver. I checked into that already also. First I used my own nameserver, where the output just looks as yours. dig +noall +stats +comment -t mx et.lindenberg.one | grep -E '^;; (flags|SERVER):' ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) But later I changed to to the nameservers from my hoster, where the output looks like this: dig +noall +stats +comment -t mx et.lindenberg.one | grep -E '^;; (flags|SERVER):' ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 6 ;; SERVER: 185.12.64.1#53(185.12.64.1) (UDP) So that can't be the cause from my knowledge point. >Or, more likely, you're not using DANE at all, either because it is not >enabled in your Exim configuration, or because you don't have a >validating local resolver in /etc/resolv.conf, or it does have >"options trust-ad" (needed on recent glic systems). >Which then leads to no default SNI, and then to the problematic >keyUsage. >DANE is not actually taking place. All I can see is, that DANE takes place (for the OpenSSL based exim), as I pass the test from https://blog.lindenberg.one/EmailSecurityTest Analysis Mailserver (Prio) Adresse(n) Aussteller Rootzertifikat DNSSEC STARTTLS TLS Version Zertifikat Passende TLSA MTA-STS mx.sub.myDomain.de (10) 159.69.xx.xx ISRG Root X1 Mx, A, Tlsa Success 1.3 Trustworthy Ok No Policy ? Obligatorische Transportverschlüsselung ? ? ? Qualifizierte Transportverschlüsselung ? ? ? ? RFC 7672 SMTP-DANE ? ? ? ? ? RFC 8461 MTA-STS ? ? ? ? Summary ? ? ? ? ? ? Netzwerkinformationen My mailserver avoided untrusted certs, but was sending to the TLSA-trusted cert. >> I did a tcpdump on my test environment, sending mails to a couple of >> domains, DANE secure, without >> DANE, but enforcing STARTTLS and such, allowing STARTTLS. >> I did this three times, using different compiled exims for the same >> configuration: >> - the distribution original exim "Exim version 4.96" >> - my own compiled exim with OpenSSL-GNU from debian "Exim version 4.97.1" >> - my own compiled exim with self compiled "openssl-3.3.1" "Exim version >> 4.97.1" >> all connections were established without using SNI, just a plain "Client >> Hello" in the dump! >> Two servers with "Exim version 4.93" are also not sending SNI in TLS. >You really should have included the "Transport Layer Security" portion >of the packet that includes the TLS Client Hello. But if the problem >is at the DNS layer, this is not surprising, so perhaps not needed. I enclose two full logs, one with the GNU-TLS Version of exim and the other with the OpenSSL Version >-- > Viktor.
logs.tgz
Description: Binary data
-- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/ ## unsubscribe (doesn't require an account): ## exim-users-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
