[exim] Follow-Up: Debug TLS/DANE problems / GnuTLS?

Góra strony
Delete this message
Reply to this message
Autor: Wolfgang
Data:  
Dla: exim-users
Temat: [exim] Follow-Up: Debug TLS/DANE problems / GnuTLS?
Hello,

still trying to debug, why my exim is denying connection to mx06.lindenberg.one (see:https://blog.lindenberg.one/EmailSecurityTest
)
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).
The result matches my own findings:

>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.

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)...
>
>==== 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 would have expected some other results, explaining why gnutls inside exim tells me:
"Key usage violation in certificate has been detected"

Still thankful for some more hints

Regards

    Wolfgang



--
## 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/