[exim] TLS SNI possibly breaking "verify = certificate"

Etusivu
Poista viesti
Vastaa
Lähettäjä: Mark Hills
Päiväys:  
Vastaanottaja: exim-users
Aihe: [exim] TLS SNI possibly breaking "verify = certificate"
"verify = certificate" no longer passes after some system upgrade.

My systems running OpenSMTPD submit mail to an Exim smarthost.

Authentication used "verify = certificate", then checks for known
certificate fingerprint. This has worked for many years. Extracts from
configuration at the end of this mail.

But now "verify = certificate" no longer passes in _one_ case (others are
fine), which becomes my test case:

- client: opensmtpd 7.4.0p1-r1 (Alpine Linux 3.19.1)

- smarthost: exim 4.97.1_4 (FreeBSD 13.2-RELEASE-p11)

The client certificate has not been changed.

I also tested copying over the key + cert (and HELO identity) from a
working system, and it did not work on this system.

Using exim's +all logging is not very insightful; the result of a 'diff'
is that authentication simply disappeared:

SSL SSL_accept,state_chg: SSLv3/TLS write finished
SSL SSL_accept,state_chg: TLSv1.3 early data
SSL SSL_accept,state_chg: TLSv1.3 early data
-SSL authenticated verify ok: depth=0 SN=/C=GB/L=London/CN=xxxxxx
SSL SSL_accept,state_chg: SSLv3/TLS read client certificate
-SSL SSL_accept,state_chg: SSLv3/TLS read certificate verify

Further up the logs, is the only tangible difference I can see is SNI
being sent by the (newer) OpenSMTPd client:

SSL SSL_accept,state_chg: before SSL initialization
SSL SSL_accept,state_chg: before SSL initialization
+Received TLS SNI "mail.xxxxxxxxxx.uk" (unused for certificate selection)
SSL SSL_accept,state_chg: SSLv3/TLS read client hello

The only other differences appear to be secrets, hostnames, PIDs, memory
addresses etc..

So where to go from here:

1) sending SNI is breaking "verify = certificate" at Exim? or

2) some other TLS change which is invisible in the Exim log; or

3) some other cause at the client which still allows working TLS but is
not visible to exim.

I'm unsure to what extent (2) or (3) are even possible.

If I move on to testing (1) I'll need to modify the client code, but how
likely is this if Exim is documented as ignoring this?

Or something different entirely.

Thanks

--
Mark


tls_privatekey = /etc/ssl/local.key
tls_certificate = /etc/ssl/lets.crt
tls_advertise_hosts = *
tls_verify_certificates = /etc/ssl/certs/
tls_try_verify_hosts = *

RELAY_FROM_CERTS =\
    702B4xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: \
    EA37Exxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


acl_check_rcpt:

  accept  verify = certificate
          condition = ${if inlist{${sha256:$tls_in_peercert}}{RELAY_FROM_CERTS}}
          control = dkim_disable_verify
          logwrite = accepting message from certified connection ${substr{0}{6}{${sha256:$tls_in_peercert}}}


# end

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