On Sat, Jul 13, 2024 at 09:46:25PM +0200, Wolfgang via Exim-users wrote:
> and all others helping me, to find the problem with my exim not able to deliver to the
> https://blog.lindenberg.one/EmailSecurityTest .
It sure looks to my expert eyelike you've still failed to identify the
reason for the missing SNI, which *is* the underlying problem. The
subsequent issue with keyUsage is a *consequence.
> So finally I have created a testenvironment, which had all the destinations with and without DANE,
> letsencrypt etc. I created identical looking self signed certs, removed the usual BasicConstraints
> CA=FALSE, which all my self-signed certs have, so my cert looked just the same.
> gnutls-cli -d 9999 -V -p 25 85.215.77.84 --starttls-proto=smtp
> ASSERT: ../../lib/tls-sig.c[_gnutls_check_key_usage_for_sig]:58
> Peer's certificate does not allow digital signatures. Key usage violation detected.
> *** Fatal error: Key usage violation in certificate has been detected
This is the symptom, the direct cause is the default (non-SNI)
certificate presented by the remote system, with the indirect
cause (real problem) being the missing SNI, which leads to the
wrong certificate being presented.
> Doing the same to my test-destination for the self-signed cert:
> gnutls-cli -d 9999 -V -p 25 78.46.150.68 --starttls-proto=smtp
> Status: The certificate is NOT trusted. The name in the certificate does not match the expected.
> *** Fatal error: Error in the certificate
This is a certificate with a compatible keyUsage.
> Ok, I compared the the certs again and they just looked identical:
> Issuer: OU=GnuTLS test,O=xxxxxxxxxxxxxxx,L=Karlsruhe,ST=BW,C=DE Issuer: CN=et.lindenberg.one,OU=Tests,O=Lindenberg,L=Karlsruhe,ST=BW,C=DE
> Validity: Validity:
> Not Before: Sat Jul 13 18:08:35 UTC 2024 Not Before: Sat Jan 22 16:08:03 UTC 2022
> Not After: Tue Jul 11 18:08:35 UTC 2034 Not After: Fri Jan 17 16:08:03 UTC 2042
> Subject: CN=xxxxxxx.sxxxxxxxxxxxxxx.de,OU=GnuTLS test,O=xxxxxxxxxxxxxx,L=Karlsruhe,ST=BW,C=DE Subject: CN=et.lindenberg.one,OU=Tests,O=Lindenberg,L=Karlsruhe,ST=BW,C=DE
> [...]
> Extensions: Extensions:
> Key Usage (not critical): Key Usage (not critical):
> Key encipherment. Key encipherment.
> Data encipherment. Data encipherment.
These certificates have the problem keyUsage, and are only compatible
with RSA key exchange, which is only available with TLS 1.2 and prior.
GnuTLS will reject this for TLS 1.3, or with TLS 1.[0-2] and ephemeral
key exchange.
> When I check now my certificate:
> certtool -i -d 9999 -V -e --verify-profile high --infile=gnutls-test03.crt
> I get only a warning:
> Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown
That's not checking compatibility with TLS, only the trust path is
checked.
> When I check the testinstance certificate, I get this output:
> Chain verification output: Not verified. The certificate is NOT trusted.
> The certificate chain violates the signer's constraints.
Red herring, due to a flawed test. The SNI issue remains unresolved.
--
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-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
