Exim – Updated EXIM4 Not Using TLS Due to Validation Failure

exim

I have a home server and updated the system drive to an SSD as it had been on a combination of USB and HDD for /home and /var. Because the USB was on a previous version of Debian I have done a fresh install, which has also upgraded me to version 4.95 of EXIM, previously I was on 4.94.2.

Despite the same smarthost configuration, to use my ISP's SMTP server, it no longer uses TLS and gives a validation error.

/var/log/exim4/mainlog:

2022-04-12 03:30:25 1ne6I7-000AHw-MF TLS session: (certificate verification failed): delivering unencrypted to H=<DOMAIN> [<IP>] (not in hosts_require_tls)

The mail is still accepted unencrypted, but now mail from cron jobs is being flagged by my I.S.P. as spam. The only change being messages being a Received header which has gone from being with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) to just with esmtp (Exim 4.95). So presumably that difference is what is flagging it for extra attention.

I had been using the same self-signed key and certificate (with a 2013) timestamp as the previous installation. I also tried generating a new pair with similar lack of effect.

After searching online for advice it was suggest to use a letsencrypt configuration so it could be validated. I already use that, but it caused the same behaviour in EXIM.

This is my configuration

/etc/exim4/update-exim4.conf.conf:

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='<LOCAL DOMAIN>'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='<ISP DOMAIN>:587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'

/etc/exim4/etc/exim4/conf.d/main/00_local_settings:

MAIN_TLS_ENABLE = yes
MAIN_TLS_CERTIFICATE = /etc/letsencrypt/live/<LOCAL DOMAIN>/fullchain.pem
MAIN_TLS_PRIVATEKEY = /etc/letsencrypt/live/<LOCAL DOMAIN>/privkey.pem

/etc/letsencrypt/archive/<LOCAL DOMAIN>/*15.*

-rw-r--r-- 1 root Debian-exim 1870 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/cert15.pem
-rw-r--r-- 1 root Debian-exim 3749 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/chain15.pem
-rw-r--r-- 1 root Debian-exim 5619 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/fullchain15.pem
-rw------- 1 root Debian-exim 1708 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/privkey15.pem

I also have /etc/exim4/passwd.client file with my SMTP login details, and which obviously is working to be sending mail at all.

is a domain which points to my home IP addrress.

The entries to the letsencrypt keys in 00_local_settings point to its symlinks that go to the current versions. On those I have changed the group ownership so that EXIM can see the private key, but leave the permissions alone.

My previous working configuration was the same, but with the self-signed exim.crt and exim.key files in /etc/exim4, and so without the latter two lines in my 00_local_settings file.

I have also tried copying the letsencrypt files into /etc/exim4 and naming them exim.cert and exim.key with the same permissions of 640 and nothing in 00_local_settings but it did not change anything.

What is particularly annoying is that as a final test I just deleted the keys with no configuration for them to see what would happen. I got the same error, so I am cannot tell whether there is a problem with the keys I have used, or it is just not even seeing them at all.

Best Answer

I have continued to research and I have found an answer, of sorts. It was not clear to me whose certificate was being verified, I had assumed mine but realized it could be the one of the remote SMTP server.

Adding the entry below to /etc/exim4/etc/exim4/conf.d/main/00_local_settings disables verification, allows TLS to be used.

REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = !*

This can be confirmed in a message header which now shows it being received with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)

I assume this is what was happening before and that either Debian or Exim have changed the default to require verification since my initial configuration.

Presumably if the remote server uses a self-generated certificate it cannot be verified?

Related Topic