Exim and gnutls - A TLS fatal alert has been received

Posted: 2016-06-03 23:52:16 by Alasdair Keyes

Direct Link |

---

Whilst diagnosing why an email wasn't getting through to me, I noticed the following errors appearing occasionally in my Exim logs.

"2016-06-03 20:20:36 TLS error on connection from servername (servername) [1.2.3.4] (gnutls_handshake): A TLS fatal alert has been received.

Anything producing the words 'fatal' in logs are cause for alarm and it wasn't something I'd seen before so I did a bit of investigation and found that it was due to the TLS certificate I have for exim not having a common name set that matches the hostname that the remote server was connecting to.

My certificate had akeyes.co.uk and www.akeyes.co.uk however my MX records are mail.akeyes.co.uk, this doesn't really cause an error, mail is still accepted, however at some point in future (and some very strict mail servers) may refuse such connections so it's best to get it fixed.

To diagnose the issue, lets try connecting on a hostname that is not on the certificate, as I was on the server, 127.0.0.1 would do fine. As exim is compiled against gnutls we'll need to use the gnutls command line tools..

apt-get install gnutls-bin -y

Then connect using gnutls-cli bold red text is what I typed and bold blue text is the useful part of the response

# gnutls-cli -s -p 25 127.0.0.1
Processed 174 CA certificate(s).
Resolving '127.0.0.1'...
Connecting to '127.0.0.1:25'...
- Simple Client Mode:
220 vps2.akeyes.co.uk ESMTP Exim 4.84_2 Fri, 03 Jun 2016 20:40:55 +0100
ehlo me
250-vps2.akeyes.co.uk Hello localhost [127.0.0.1]
250-SIZE 104857600
250-8BITMIME
250-PIPELINING
250-STARTTLS
250 HELP
starttls
220 TLS go ahead
<CTRL-D>
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=akeyes.co.uk', issuer `C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3', RSA key 2048 bits, signed using RSA-SHA256, activated `2016-06-03 18:35:00 UTC', expires `2016-09-01 18:35:00 UTC', SHA-1 fingerprint `d0b48bf7056860c48ab204e246b5ec95dcac42f4'
    Public Key ID:
        4d601b2e453c98b68ac88addd946de73982b6cac
    Public key's random art:
        +--[ RSA 2048]----+
        |       =*        |
        |      ++o+       |
        |     ...o..      |
        |      .. o       |
        |.. . .  S .      |
        |... . .          |
        |o. . B . o       |
        |o . o O = .      |
        |    E+ ..+       |
        +-----------------+
- Certificate[1] info:
 - subject `C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3', issuer `O=Digital Signature Trust Co.,CN=DST Root CA X3', RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', SHA-1 fingerprint `e6a3b45b062d509b3382282d196efe97d5956ccb'
- Status: The certificate is NOT trusted. The name in the certificate does not match the expected. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed

I then ran the same command but using a hostname I knew was on the certificate

# gnutls-cli -s -p 25 akeyes.co.uk
Processed 174 CA certificate(s).
Resolving 'akeyes.co.uk'...
Connecting to '178.62.80.10:25'...
- Simple Client Mode:
220 vps2.akeyes.co.uk ESMTP Exim 4.84_2 Sat, 04 Jun 2016 00:02:08 +0100
ehlo me
250-vps2.akeyes.co.uk Hello vps2.akeyes.co.uk [178.62.80.10]
250-SIZE 104857600
250-8BITMIME
250-PIPELINING
250-STARTTLS
250 HELP
starttls
220 TLS go ahead
<CTRL-D>
*** Starting TLS handshake
- Certificate type: X.509
...
...
- Status: The certificate is trusted. 
...
...

So we can see why this error is occuring, the easy fix is to ensure that the certificate used by Exim has all required hostnames. I use letsencrypt so I just regenerated a certificate and added -d mail.akeyes.co.uk switch. Alternatively, change the MX records for all domains your server handles mail for, to a hostname which is included on the certificate.

Oh, and in case you were wondering, the cause of the mail getting through was misconfiguration of the sender's DNS. The hostname part of his email address was a subdomain which had no DNS record so sender verification failed.

If you found this useful, please feel free to donate via bitcoin to 1NT2ErDzLDBPB8CDLk6j1qUdT6FmxkMmNz