Thunderbird does not trust the mail certificate — an incomplete Dovecot TLS chain

An email client can report a certificate problem even when the certificate has not expired, matches the server name, and was issued by a trusted CA. In that situation, the cause may not be the domain certificate itself but an incomplete chain sent by the server.

In this case, Thunderbird did not trust an IMAPS connection. Instead of changing the client settings or adding a security exception, I started by checking what the server actually presented on port 993.

Test the certificate externally

The connection can be checked with openssl s_client:

openssl s_client \
  -connect mail.example.com:993 \
  -servername mail.example.com \
  -verify_return_error </dev/null 2>&1 | \
grep -E 'depth=|verify error|Verify return code'

The -servername argument sends the hostname through SNI. Redirecting input from /dev/null closes the connection after the TLS test instead of leaving an interactive IMAP session open.

A result ending with a message like this indicates a chain verification problem:

Verify return code: 21 (unable to verify the first certificate)

This does not automatically mean that the server certificate is invalid. The client may simply be missing the intermediate certificate needed to build a trusted path.

`cert.pem`, `chain.pem`, and `fullchain.pem`

Certbot keeps several files associated with the same certificate:

cert.pem — the server certificate only,
chain.pem — the intermediate certificate or certificates,
fullchain.pem — the server certificate followed by the intermediates,
privkey.pem — the private key, which must remain protected.

These files are described in the Certbot documentation.

You can quickly check how many certificates fullchain.pem contains:

grep -c 'BEGIN CERTIFICATE' \
  /etc/letsencrypt/live/mail.example.com/fullchain.pem

The file should contain the server certificate and at least one intermediate. A typical result is 2, although the exact chain length may change.

Correct configuration in Dovecot 2.3

In Dovecot 2.3, the file configured as ssl_cert should contain the certificate presented to the client together with the required chain. For a certificate managed by Certbot, the configuration can look like this:

ssl = yes
ssl_cert = </etc/letsencrypt/live/mail.example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.example.com/privkey.pem

The < prefix matters: it tells Dovecot to read the contents of the specified file. The settings are covered in the Dovecot 2.3 TLS documentation.

Setting ssl_ca does not append an intermediate to the chain presented to the client. In Dovecot 2.3, that option is used, among other things, for CAs that validate client certificates. It is usually unnecessary for ordinary password-based IMAPS authentication.

Dovecot 2.4 renamed many TLS settings, including ssl_cert to ssl_server_cert_file and ssl_key to ssl_server_key_file. Check the installed version and the 2.3 to 2.4 upgrade guide before changing the configuration.

Check before reloading

First, verify that Dovecot can parse the configuration:

doveconf -n >/dev/null && echo "Dovecot configuration OK"

Then inspect the active TLS settings:

doveconf -n | grep -E '^ssl_(cert|key|ca)'

If the configuration is valid, reload the service without interrupting existing connections with a full restart:

systemctl reload dovecot

Repeat the external test after the reload. The expected result is:

Verify return code: 0 (ok)

What actually resolved the problem

The problem was not Thunderbird or the certificate validity period. Dovecot presented only the server certificate without the required intermediate. Configuring fullchain.pem as ssl_cert, validating the configuration, and reloading the service restored correct TLS verification.

This is a good example of why certificate errors should be tested from the client side. The fact that Certbot files exist and are current does not guarantee that a daemon presents the correct chain.