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-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
