Package: exim4/stable,stable-security Version 4.96-15+deb12u4 all Package: exim4/focal-updates,focal-security Version: 4.93-13ubuntu1.10 all
Problem occurs in sending mails to a DANE protected MX, under certain conditions. I run into an problem, that my mailserver can't deliver mails to an perfect configured Mailserver, which uses DANE authorization. The configuration used by this mailserver is a little bit tricky, but 100% compliant to all conditions needed for DANE. The tricky configuration is described here: https://blog.lindenberg.one/EmailSecurityTest as this is part of an email security test, which does much more then the usual fair-weather tests. The problem arises, when my mailserver tries to deliver a mail to mx06.et.lindenberg.one, which has a valid letsencript certificate, which is signed from the R3 intermediate. The server sends its own certificate including the intermediate, which can be proofed with openssl s_client. Testing this needs some time, as the server refuses the first connection tries (read the linked description). Mr. Lindenberg, who runs this test, will support testing this issue by adding client IP to his database, to offer immediate STARTTLS, when asking him. The problem looks like this: The receiving MX has DANE RRs, where one of those signs the key of the letsencrypt intermediate R3, which signs the cert, the MX uses. The host cert has a cname, which is different to the MX host, but one of the SANs embedded in this certificate matches the MX hostname. This is a valid setup. This shows how that ties together: +--------------+ |intermediate | |letsencrypt | | R3 | |key: xxx |<--- TLSA RR signs this key (checked and valid) | | +--------------+ | | <-- signs the server cert, valid by signature and timeframe | V +------------------+ | end certificate | | key:2222 | | cname: a.test.xy | | | | SANs: | | b.test.xy | | c.test.xy | | d.test.xy | | e.test.xy | | f.test.xy | | g.test.xy | | h.test.xy | | MX.test.xy |<----- this is the MX host name +------------------+ But my exim reports for each connection: > 2024-06-30 21:04:43 1sNzqt-000Rs3-C7 == [email protected] R=dnslookup > T=remote_smtp defer (-37) \ > H=mx06.et.lindenberg.one [85.215.77.84]: TLS session: (gnutls_handshake): \ > Key usage violation in certificate has been detected. Unfortunately exim has no further debugging/logging methods, as it relies on GNU-TLS. To make it short, I don't list all things I tried, but my last steps, leading to an result: 1) SETUP NEW CLEAN TESTENVIRONMENT ---------------------------------- I have set up a virtual server with its own sub-domain, completly DANE,DKIM,SPF equipped. I used the most current devuan daedalus aka debian bookworm. With this i got an "Exim version 4.93 #3 built 11-Jan-2024 13:28:33" I kept the configuration as original as possible, just configured the pure needed configuration changes. And: The problem occured even here! A test with this version was also unsuccesful. Exim was not able to verify the DANE-target positiv! 2) COMPILE CURRENT EXIM 4.97.1 with GNU-TLS ------------------------------------------- Now I decided to download and compile the 4.97.1 version of exim. In my first try, I compiled it similar to the debian 4.93, also using Gnu-TLS. And: The problem occured even here. A test with this version was also unsuccesful. Exim was not able to verify the DANE-target positiv! 3) COMPILE CURRENT EXIM 4.97.1 with OPENSSL (Debian Way) -------------------------------------------------------- Now I decided to compile the 4.97.1 version of exim against Openssl. I installed libssl-dev and compiled exim. In my first try, this exim reported with exim -bV that it supports OpenSSL, but when starting it productive, it claims, that GNU-TLS can't understand the CIPHERS, I changed to the OpenSSL rules. WAIT! What? Yes: exim reports to support OpenSSL, but under the hood it is still GNU-TLS! https://packages.debian.org/bookworm/amd64/libssl-dev/filelist reveals, that debian installs the expected OpenSSL header files, but they are only a wrapper to GNU-TLS Libraries, having the expected OpenSSL names!! Still tried this version after setting the CIPHERS back to GNU-TLS syntax. Maybe the wrapper removed some glitches, bot NO. But I am still not able to deliver mails! 4) COMPILE CURRENT EXIM 4.97.1 with OPENSSL NATIVE -------------------------------------------------- Ok, now I dowloaded OpenSSL 3.3.1 as well, compiled and installed it. I afterwards build exim against this OpenSSL installation. And? SUCCESS!! Now I was able to deliver also all mails from prior test, still living in the queue. So for me its clear, that the issue is related to the combination of exim and gnu-tls. I can only guess, where the problem occurs. But as it works with OpenSSL, but not with core GNU-TLS and not with the wrapped GNU-TLS, where exim assumes, that it uses OpenSSL I assume, that the problem may somewhere in GNU-TLS. I tried to dig a little bit deeper using the GNU-TLS danetool like this: > danetool --check mx06.et.lindenberg.one --proto tcp --port 25 The resulting reports raises some questions: >Resolving 'mx06.et.lindenberg.one:smtp'... >Obtaining certificate from '85.215.77.84:25'... >Querying DNS for mx06.et.lindenberg.one (tcp:25)... > >==== Entry 1 ==== >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 >025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d ) >Certificate usage: Local CA (02) >Certificate type: SubjectPublicKeyInfo (01) >Contents: SHA2-256 hash (01) >Data: 025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d > >Verification: Certificate matches. > >==== Entry 2 ==== >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 >276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ) >Certificate usage: Local CA (02) >Certificate type: SubjectPublicKeyInfo (01) >Contents: SHA2-256 hash (01) >Data: 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 > >Verification: Certificate matches. > >==== Entry 3 ==== >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 >2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba ) >Certificate usage: Local CA (02) >Certificate type: SubjectPublicKeyInfo (01) >Contents: SHA2-256 hash (01) >Data: 2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba > >Verification: Certificate matches. > >==== Entry 4 ==== >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 >6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7 ) >Certificate usage: Local CA (02) >Certificate type: SubjectPublicKeyInfo (01) >Contents: SHA2-256 hash (01) >Data: 6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7 > >Verification: Certificate matches. > >==== Entry 5 ==== >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 >8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ) >Certificate usage: Local CA (02) >Certificate type: SubjectPublicKeyInfo (01) >Contents: SHA2-256 hash (01) >Data: 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d > >Verification: Certificate matches. > >==== Entry 6 ==== >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 >919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 ) >Certificate usage: Local CA (02) >Certificate type: SubjectPublicKeyInfo (01) >Contents: SHA2-256 hash (01) >Data: 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 > >Verification: Certificate matches. > >==== Entry 7 ==== >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 >bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ) >Certificate usage: Local CA (02) >Certificate type: SubjectPublicKeyInfo (01) >Contents: SHA2-256 hash (01) >Data: bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 > >Verification: Certificate matches. > >==== Entry 8 ==== >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 >e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ) >Certificate usage: Local CA (02) >Certificate type: SubjectPublicKeyInfo (01) >Contents: SHA2-256 hash (01) >Data: e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 > >Verification: Certificate matches. > >==== Entry 9 ==== >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 >f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888 ) >Certificate usage: Local CA (02) >Certificate type: SubjectPublicKeyInfo (01) >Contents: SHA2-256 hash (01) >Data: f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888 > >Verification: Certificate matches. > What is gnutls comparing? Why it tells me, that all 9 tlsa-RRs are matching? I compared that against OpenSSL output: > echo "quit" | openssl s_client -starttls smtp -connect > mx06.et.lindenberg.one:25 -4 -verify 9 \ > -dane_tlsa_domain mx06.et.lindenberg.one \ > -dane_tlsa_rrdata "2 1 1 > BD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422E0C89270"\ > -dane_tlsa_rrdata "2 1 1 > E5545E211347241891C554A03934CDE9B749664A59D26D615FE58F77990F2D03"\ > -dane_tlsa_rrdata "2 1 1 > F1647A5EE3EFAC54C892E930584FE47979B7ACD1C76C1271BCA1C5076D869888"\ > -dane_tlsa_rrdata "2 1 1 > 025490860B498AB73C6A12F27A49AD5FE230FAFE3AC8F6112C9B7D0AAD46941D"\ > -dane_tlsa_rrdata "2 1 1 > 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10"\ > -dane_tlsa_rrdata "2 1 1 > 2BBAD93AB5C79279EC121507F272CBE0C6647A3AAE52E22F388AFAB426B4ADBA"\ > -dane_tlsa_rrdata "2 1 1 > 6DDAC18698F7F1F7E1C69B9BCE420D974AC6F94CA8B2C761701623F99C767DC7"\ > -dane_tlsa_rrdata "2 1 1 > 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D"\ > -dane_tlsa_rrdata "2 1 1 > 919C0DF7A787B597ED056ACE654B1DE9C0387ACF349F73734A4FD7B58CF612A4"\ > -sigalgs > rsa_pkcs1_sha256:rsa_pkcs1_sha384:rsa_pkcs1_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha5 >CONNECTED(00000003) >--- >Certificate chain > 0 s:CN = et.lindenberg.one > i:C = US, O = Let's Encrypt, CN = R3 > 1 s:C = US, O = Let's Encrypt, CN = R3 > i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 >--- >Server certificate >-----BEGIN CERTIFICATE----- >MIIHFjCCBf6gAwIBAgISA2gKPw3hnIK3DhYzXdhVWUfPMA0GCSqGSIb3DQEBCwUA >..... >lO5QmymMYK9k2VuNDI9WKFaKfnF+LVVhYyzbyNT/uGbFdIhrhF/f5rES >-----END CERTIFICATE----- >subject=CN = et.lindenberg.one > >issuer=C = US, O = Let's Encrypt, CN = R3 > >--- >No client certificate CA names sent >Peer signing digest: SHA256 >Peer signature type: RSA-PSS >Server Temp Key: X25519, 253 bits >--- >SSL handshake has read 4021 bytes and written 391 bytes >Verification: OK >Verified peername: mx06.et.lindenberg.one >DANE TLSA 2 1 1 ...a0a20afadb5813dcfbcf286d matched TA certificate at depth 1 >--- >New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 >Server public key is 4096 bit >Secure Renegotiation IS NOT supported >Compression: NONE >Expansion: NONE >No ALPN negotiated >Early data was not sent >Verify return code: 0 (ok) >--- It verifies the second last tlsa-RR, which is the only RR, which really matches. Regards Wolfgang
