Thunderbird nie ufa certyfikatowi poczty — niepełny łańcuch TLS w Dovecocie

Klient pocztowy może zgłaszać problem z certyfikatem, mimo że certyfikat nie wygasł, pasuje do nazwy serwera i został wystawiony przez zaufane CA. W takim przypadku przyczyną może być nie sam certyfikat domeny, ale niepełny łańcuch wysyłany przez serwer.

W opisanym przypadku Thunderbird nie ufał certyfikatowi połączenia IMAPS. Zamiast zmieniać ustawienia klienta lub dodawać wyjątek bezpieczeństwa, zacząłem od sprawdzenia tego, co serwer faktycznie udostępnia na porcie 993.

Test certyfikatu z zewnątrz

Do sprawdzenia połączenia wystarczy 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'

Parametr -servername wysyła nazwę hosta przez SNI. Przekierowanie z /dev/null zamyka połączenie po teście TLS, zamiast pozostawiać interaktywną sesję IMAP.

Wynik kończący się komunikatem podobnym do tego wskazuje na problem z weryfikacją łańcucha:

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

Nie oznacza to automatycznie, że certyfikat serwera jest nieważny. Klient może po prostu nie otrzymywać certyfikatu pośredniego potrzebnego do zbudowania ścieżki zaufania.

`cert.pem`, `chain.pem` i `fullchain.pem`

Certbot przechowuje kilka plików związanych z tym samym certyfikatem:

cert.pem — wyłącznie certyfikat serwera,
chain.pem — certyfikat lub certyfikaty pośrednie,
fullchain.pem — certyfikat serwera, a za nim certyfikaty pośrednie,
privkey.pem — klucz prywatny, który musi pozostać chroniony.

Pełny opis tych plików znajduje się w dokumentacji Certbota.

Można szybko sprawdzić, ile certyfikatów zawiera fullchain.pem:

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

Plik powinien zawierać certyfikat serwera i co najmniej jeden certyfikat pośredni. W typowym przypadku wynikiem będzie 2, choć dokładna długość łańcucha może się zmieniać.

Poprawna konfiguracja w Dovecot 2.3

W Dovecot 2.3 plik podany jako ssl_cert powinien zawierać certyfikat przedstawiany klientowi wraz z potrzebnym łańcuchem. Dla certyfikatu zarządzanego przez Certbota konfiguracja może wyglądać tak:

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

Znak < jest istotny: oznacza, że Dovecot ma wczytać zawartość wskazanego pliku. Opis ustawień znajduje się w dokumentacji TLS Dovecota 2.3.

Samo ustawienie ssl_ca nie uzupełnia łańcucha przedstawianego klientowi. W Dovecot 2.3 opcja ta służy m.in. do określenia CA używanych przy weryfikowaniu certyfikatów klientów. Przy zwykłym logowaniu IMAPS za pomocą hasła zazwyczaj nie jest do tego potrzebna.

Dovecot 2.4 zmienił nazwy wielu ustawień TLS, między innymi ssl_cert na ssl_server_cert_file i ssl_key na ssl_server_key_file. Przed zmianą konfiguracji sprawdź zainstalowaną wersję i instrukcję migracji z 2.3 do 2.4.

Sprawdzenie przed przeładowaniem

Najpierw warto sprawdzić, czy Dovecot poprawnie parsuje konfigurację:

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

Następnie można zobaczyć aktywne ustawienia TLS:

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

Jeżeli konfiguracja jest poprawna, wystarczy przeładować usługę bez zrywania istniejących połączeń pełnym restartem:

systemctl reload dovecot

Po przeładowaniu należy ponowić test z zewnątrz. Oczekiwany rezultat to:

Verify return code: 0 (ok)

Co faktycznie rozwiązało problem

Problem nie leżał w Thunderbirdzie ani w ważności certyfikatu. Dovecot przedstawiał klientowi sam certyfikat serwera, bez potrzebnego certyfikatu pośredniego. Wskazanie fullchain.pem jako ssl_cert, sprawdzenie konfiguracji i wykonanie reload przywróciły poprawną weryfikację TLS.

To dobry przykład, dlaczego przy błędach certyfikatów warto sprawdzać usługę od strony klienta. Sam fakt, że pliki Certbota istnieją i są aktualne, nie gwarantuje jeszcze, że daemon wysyła właściwy łańcuch.