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

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.

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/[email protected] 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>[email protected]</username>
    </incomingServer>
    <outgoingServer type="smtp">
      <hostname>mail.example.com</hostname>
      <port>587</port>
      <socketType>STARTTLS</socketType>
      <authentication>password-encrypted</authentication>
      <username>[email protected]</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:

1. Let´s Encrypt ACMEv2 supports wildcards, although configuring it requires some experience.

2. 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
   

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.