On Fri, Jul 05, 2024 at 02:01:38PM +0200, Wolfgang via Exim-users wrote:
> I am much more familar with openssl, but debian-exim is linked against
> gnu-tls, so I started digging in gnttls binary tools also.
> Unfortunately gnutls-cli is far less capable, that the openssl cli
> tools. I started the following openssl-test:
>
> >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
>
> the dane_tls_rrdata are the dns RR, i got before from a dns-lookup (as I
> found here now way, to tell
> openssl to do that by its own).
That's deliberate, OpenSSL does not want to depend on api particular DNS
API, some of which in turn depend on OpenSSL, nor is the OpenSSL DANE
support limited to TLSA records obtained from DNS, in various important
use-cases the TLSA records are locally synthesised. It is easy to write
a shell function that does the DNS lookups for you, and the invokes
"s_client" with the right arguments:
danesmtp () {
local OPTIND=1 opt
local -a rrs sslopts
local rr i=0 host addr
while getopts a: opt; do
case $opt in
a) addr=$OPTARG
case $addr in
*:*) addr="[$addr]" ;;
esac;;
*) printf 'usage: danesmtp [-a addr] host [ssloption ...]\n'
return 1 ;;
esac
done
shift $((OPTIND - 1))
host=$1; shift
if [[ -z "$addr" ]]; then addr="$host"; fi
sslopts=(
-starttls smtp
-connect "$addr:25"
-brief
-verify 9
-verify_return_error
-dane_ee_no_namechecks
-dane_tlsa_domain "$host"
)
rrs=($(dig +short +nosplit -t tlsa "_25._tcp.$host" |
grep -Ei '^[23] [01] [012] [0-9a-f]+$'))
while (( i < ${#rrs[@]} - 3 )); do
rr=${rrs[@]:$i:4}
i=$((i+4))
sslopts=("${sslopts[@]}" "-dane_tlsa_rrdata" "$rr")
done
( sleep 1; printf "QUIT\r\n" ) |
openssl s_client "${sslopts[@]}" "$@"
}
> The result matches my own findings:
>
> >Verification: OK
> >Verified peername: mx06.et.lindenberg.one
> >DANE TLSA 2 1 1 ...a0a20afadb5813dcfbcf286d matched TA certificate at depth 1
> >Verify return code: 0 (ok)
Yes, the host in question has a certificate chain that matches one of
its "2 1 1" (R3) TLSA records. The EE cert keyUsage and
extendedKeyUsage look normal:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
and unsurprisingly "R3" is fine as well.
> Now I used the gnutls danetool, which is capable to pull the tlsa-RRs from
> DNS.
>
> > 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)...
> >
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01
> >025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01
> >276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01
> >2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01
> >6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7 )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01
> >8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01
> >919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01
> >bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01
> >e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01
> >f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888 )
> >Verification: Certificate matches.
>
> What is gnutls comparing? Why it tells me, that all 9 tlsa-RRs are
> matching?
The most charitable interpretation of the above is that the status
reported is global, rather than per TLSA record, and so for each
RR it reports the same fact, that some TLSA record matched?
Otherwise, it does seem non-sensical. If you want working DANE support
in Exim, use the OpenSSL-based build.
> I would have expected some other results, explaining why gnutls inside
> exim tells me: "Key usage violation in certificate has been detected"
This is rather odd. The key is not being used for anything expected as
far as I can tell. FWIW, the EE certificate does specify an OSCP URI:
Authority Information Access:
OCSP - URI:http://r3.o.lencr.org
CA Issuers - URI:http://r3.i.lencr.org/
but I don't expect that the key usage issue lies there, so it is
a mystery to me.
--
Viktor.
--
## 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/
