Email server certificate valid according to CheckTLS, invalid according to Thunderbird

Question

I have set up an email server using docker-mailserver.

DKIM, SPF, and DMARC are configured fine.

SSL was set up using Let's Encrypt. Server has TLS and STARTTLS enabled.

I ran a TLS/SSL test on https://www.checktls.com/TestReceiver , and it said that my SSL works fine:

I am able to use Mozilla Thunderbird to receive and send email via the server:

However, when logging in to Thunderbird to receive email via IMAP, or when sending via SMTP, I see this warning (I am still able to send and receive email if I click on the "Confirm Security Exception" button.)

I checked a couple of other email TLS/SSL testing sites (1 and 2) and they seem to think my certs are not set up correctly ("The certificate doesn't match hostname").

Thoughts?

Update: I've managed to reach the point where imap.domainname.com is recognized by Thunderbird to have a valid certificate, but not imap.domainname.com:143. What would be a fix for this please?

If you're still having problems with the certificate, you may have to show the certificate. If it's a real CA signed certificate, you can link to it in https://crt.sh/ – I would guess you have the domain in `CN` field when you should be using `Subject Alternative Names` extensions when you have multiple subdomains. — Mikko Rantalainen, Apr 14 '22 at 13:27
Also, is this you at https://github.com/docker-mailserver/docker-mailserver/issues/1723 ? If you post your problem in multiple locations, it would be cool to post the solution to *all the same locations*, too. — Mikko Rantalainen, Apr 14 '22 at 13:28
@MikkoRantalainen Good point. I wasn't able to solve the issue yet unfortunately. — thanks_in_advance, Apr 14 '22 at 21:37

score 4 · Answer 1 · edited Dec 15 '20 at 12:58

4

The error message says exactly what your screenshots show: hostname in certificate does not match. You check your certificate with mail.yourdomain.com, and it says valid, so you created your certificate exactly for this hostname. You configure thunderbird to use imap.yourdomain.com.

Unless you configured your certificates to contain subject alternative names and include "imap.yourdomain.com" the error message is absolutely correct.

By default every certificate includes exactly one hostname, and that has to match.

Another possibility would be to purchase a wildcard certificate *.yourdomain.com. Wildcard certificates are usually more expensive while normal certificates with subject alternative names can even be free when using „lets encrypt“ and renew them every 90 days.

edited Dec 15 '20 at 12:58

Dave M

4,514
22
31
30

answered Dec 13 '20 at 08:26

Tode

1,013
9
13

Thank you, I appreciate your help. *Please note my update*. I've managed to reach the point where `imap.domainname.com` is recognized by `Thunderbird` to have a valid certificate, but not `imap.domainname.com:143`. What would be a fix for this please? – thanks_in_advance Dec 13 '20 at 16:58
2

Note that let's encrypt can provide you with a wildcard certificate for free! – kiwixz Dec 13 '20 at 18:03

score 2 · Answer 2 · edited Oct 07 '21 at 08:14

This is mismatch between the mail.example.com in the certificate and imap.example.com and smtp.example.com in the client configuration. You could either

fix the client configuration manually,
set up an autoconfiguration method to make things easier, or
simply expand the certificate to cover all the required hostnames.

Autoconfigure using DNS `SRV` records

Stardardized way (RFC 6186) for locating email submission & access servers would be using DNS SRV records. With this you could specify that both IMAP and SMTP submission are served from mail.example.com.

_imap._tcp.example.com.        SRV 0 1 143 mail.example.com.
_submission._tcp.example.com.  SRV 0 1 587 mail.example.com.

Thunderbird's Autoconfiguration

Unfortunately, Thunderbird doesn't currently support SRV records (and, according to the conversation on Bug 342242, isn't likely to implement it). However, it has another implementation for Autoconfiguration: you can serve an XML configuration file from http://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=user@example.com with e.g.

<?xml version="1.0"?>
<clientConfig version="1.1">
  <emailProvider id="example.com">
    <domain>example.com</domain>
    <displayName/>
    <incomingServer type="imap">
      <hostname>mail.example.com</hostname>
      <port>143</port>
      <socketType>STARTTLS</socketType>
      <authentication>password-encrypted</authentication>
      <username>user@example.com</username>
    </incomingServer>
    <outgoingServer type="smtp">
      <hostname>mail.example.com</hostname>
      <port>587</port>
      <socketType>STARTTLS</socketType>
      <authentication>password-encrypted</authentication>
      <username>user@example.com</username>
    </outgoingServer>
  </emailProvider>
</clientConfig>

If Thunderbird doesn't found such configuration file from that location, it defaults to using addreses imap.example.com and smtp.example.com unless you choose manual configuration.

Adding those addresses to your certificate

Alternatively, you could add those addresses to your certificate. Torsten already mentions this possibility, but suggest it would only be possible using paid wildcard certificates. That's not exactly true, as:

Let´s Encrypt ACMEv2 supports wildcards, although configuring it requires some experience.
It's not necessary to have a wildcard certificate to cover these three hostname as subject alternative names (SAN). It's possible to expand the existing certificate using Certbot, e.g.
```
certbot certonly --cert-name mail.example.com -d imap.example.com,smtp.example.com
```

Thank you, I appreciate your help. *Please note my update*. I've managed to reach the point where `imap.domainname.com` is recognized by `Thunderbird` to have a valid certificate, but not `imap.domainname.com:143`. What would be a fix for this please? — thanks_in_advance, Dec 13 '20 at 16:58
That's odd: in the *authority* part of an URL the port number isn't a part of the hostname ([RFC 3986, 3.2](https://tools.ietf.org/html/rfc3986#section-3.2)). — Esa Jokinen, Dec 13 '20 at 18:18

score 1 · Answer 3 · answered Dec 14 '20 at 08:04

1

In my case, the problems begun after an update to Thunderbird 78.5. I've solved the problems (in a limited way) after following the instructions in

https://stackoverflow.com/questions/63947262/thunderbird-78-how-to-add-security-exception

You'll have to add the ports values (separated with commas, if you have several ports) in about:config in Thunderbird to the keyword

network.security.ports.banned.override

The solution wasn't perfect: I have to desactivate the email shield in Avast to be able to send or receive email.

answered Dec 14 '20 at 08:04

Oscar Fernandez Sierra

11
1

Deactivating Avast email shield doesn't have anything to do with the original problem: the email shield feature uses its MitM position and terminates the TLS connection. Therefore, it's considered as a potential attack from Thunderbird's perspective, as it doesn't trust the certificate issued by the Avast AV. – Esa Jokinen Dec 14 '20 at 13:49
@EsaJokinen, if I don't deactive the email shield my Thunderbird doesn't connect to a email server that uses TLS 1.0 – Oscar Fernandez Sierra Mar 06 '21 at 22:19

Email server certificate valid according to CheckTLS, invalid according to Thunderbird

3 Answers3

Autoconfigure using DNS SRV records

Thunderbird's Autoconfiguration

Adding those addresses to your certificate

Autoconfigure using DNS `SRV` records