Score:1

Updated EXIM4, now not using TLS due to validation failure

gb flag

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.

us flag
look for clues in /var/log/exim4/mainlog and /var/log/exim4/paniclog
gb flag
Unfortunately there is no `paniclog` and the line I gave is the only clue in `mainlog`. The entries before and after the same as one the old Debian system, to confirm the connection and that the mail has been accepted. But for the TLS error I included everything looks normal. Not even a configuration error is logged anywhere when launching Exim. I am completely lost what to do.
Score:2
gb flag

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?

Tim Angus avatar
rs flag
Thanks! This was driving me mad.
us flag
on re-reading th log line I was about to suggest the same cause.
gb flag
It was a bit vague as to who was dong the verifying of whom as it gives no suggestion which server generated the error. Given I searched a lot to find an answer without success, hopefully having posted it here means anyone else in s similar situation will find the simple solution. Thanks for taking a look at the question though.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.