Mailserver-Zertifikate laufen unbemerkt ab

Welche Ports ein Zertifikat brauchen

Ein Mailserver spricht TLS auf mehreren Ports, und jeder davon liefert ein Zertifikat aus. Für Mailclients sind das SMTP Submission auf 587 mit STARTTLS, SMTPS auf 465 mit direktem TLS, IMAP auf 993 (direktes TLS) und 143 (STARTTLS) sowie POP3 auf 995. Für eingehende Mails von anderen Servern kommt Port 25 mit STARTTLS dazu.

Bei Postfix und Dovecot sind das zwei getrennte Dienste mit getrennten Konfigurationen, die auf dieselbe Datei zeigen können, aber nicht müssen. Es kommt regelmäßig vor, dass IMAP ein frisches Zertifikat ausliefert und SMTP ein abgelaufenes, weil nur ein Dienst neu geladen wurde.

Was passiert, wenn es abläuft

Outlook, Apple Mail und Thunderbird zeigen beim nächsten Abruf einen Dialog, der die meisten Nutzer verunsichert und den Support-Kanal füllt. Mobile Clients verhalten sich unterschiedlicher: Manche fragen, manche brechen einfach ab und zeigen "Verbindung nicht möglich", ohne das Zertifikat zu nennen. Der Nutzer sieht nur, dass keine neuen Mails kommen.

Beim Empfang von anderen Servern hängt es vom Absender ab. Die meisten Mailserver nutzen opportunistisches TLS: Schlägt die Zertifikatsprüfung fehl, liefern sie trotzdem, im Zweifel unverschlüsselt. Hat die Domain aber MTA-STS im Modus enforce oder DANE mit TLSA-Records veröffentlicht, verweigern konforme Absender wie Google und Microsoft die Zustellung, bis das Zertifikat wieder gültig ist. Genau die Domains mit der besten Mail-Sicherheit sind hier also am verwundbarsten.

Warum das Website-Monitoring nichts merkt

Ein HTTPS-Check prüft das Zertifikat auf www.beispiel.de, Port 443. Der Mailserver heißt mail.beispiel.de, läuft auf einer anderen Maschine, hat ein eigenes Zertifikat und oft eine eigene Erneuerungslogik. Bei Managed Mail wie Microsoft 365 oder Google Workspace kümmert sich der Anbieter darum. Bei selbst betriebenen Postfix- und Dovecot-Installationen, bei Plesk-Servern und bei Mailservern von kleineren Hostern ist es die Agentur oder der Kunde, und dort wird es vergessen.

Ein typisches Szenario: Die Website ist längst zu einem Hoster mit automatischen Zertifikaten umgezogen, der Mailserver läuft noch auf dem alten Root-Server mit einem Zertifikat, das jemand vor einem Jahr per Hand eingespielt hat.

Mit openssl testen

Für Ports mit direktem TLS (465, 993, 995) reicht ein normaler openssl s_client. Für STARTTLS-Ports (25, 587, 143) muss openssl erst das Klartextprotokoll sprechen und dann auf TLS umschalten, dafür gibt es die Option -starttls. Wichtig ist -servername, damit der Server bei SNI das richtige Zertifikat auswählt.

# SMTP Submission mit STARTTLS
openssl s_client -connect mail.beispiel.de:587 -starttls smtp -servername mail.beispiel.de </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

# IMAP mit direktem TLS
openssl s_client -connect mail.beispiel.de:993 -servername mail.beispiel.de </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

# IMAP mit STARTTLS
openssl s_client -connect mail.beispiel.de:143 -starttls imap -servername mail.beispiel.de </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

Prüfe jeden Port einzeln, denn genau die Diskrepanz zwischen den Diensten ist der häufigste Fehler. Der SSL Checker macht das für einen beliebigen Host und Port, inklusive STARTTLS.

Der Hostname muss zu den Clients passen

Das Zertifikat muss auf den Namen ausgestellt sein, den die Clients eintragen, also mail.beispiel.de oder imap.beispiel.de. Der interne Hostname des Servers (srv042.hoster.de) hilft nichts, wenn im Outlook des Kunden mail.beispiel.de steht. Bei Kunden, die den MX-Namen des Hosters verwenden, muss das Zertifikat auch diesen Namen abdecken.

Für Domains mit mehreren Mail-Hostnamen ist ein Zertifikat mit mehreren SANs die einfachste Lösung. Beim Empfang per MTA-STS muss das Zertifikat zusätzlich zum MX-Hostnamen passen, nicht zum Domainnamen, sonst schlägt die Policy fehl.

Let's Encrypt und der vergessene Reload

Let's Encrypt funktioniert auf Mailservern genauso wie auf Webservern. Die HTTP-01-Challenge braucht allerdings einen Webserver auf Port 80 des Mail-Hostnamens, oder du nutzt DNS-01. Plesk und viele Panels bieten das mit einem Klick an, bei einem manuell aufgesetzten Postfix richtest du certbot mit einem Deploy-Hook ein.

Der Klassiker: Das Zertifikat wurde auf der Festplatte erneuert, aber Postfix und Dovecot halten das alte im Speicher, bis sie neu geladen werden. certbot erneuert, der Cron läuft, alles sieht grün aus, und trotzdem liefern die Dienste ein abgelaufenes Zertifikat aus. Ein Deploy-Hook, der beide Dienste neu lädt, löst das dauerhaft.

# /etc/letsencrypt/renewal-hooks/deploy/mail.sh
#!/bin/sh
systemctl reload postfix
systemctl reload dovecot

In Postfix zeigen smtpd_tls_cert_file und smtpd_tls_key_file auf fullchain.pem und privkey.pem, in Dovecot sind es ssl_cert und ssl_key mit vorangestelltem Kleiner-als-Zeichen. Prüfe beides nach dem ersten Reload von außen.

Die Ports überwachen

Ein Zertifikatscheck nur auf 443 lässt den Mailserver im Dunkeln. Überwache für jede Kundendomain mit eigenem Mailserver mindestens 587 und 993, dazu 25 und 465, wenn sie genutzt werden. Prüfe dabei nicht nur das Ablaufdatum, sondern auch, ob der Hostname passt und die Kette vollständig ist.

Gestaffelte Schwellwerte bei 30, 14 und 7 Tagen geben genug Vorlauf, um den vergessenen Reload oder die kaputte Challenge zu beheben, bevor ein Kunde den ersten Zertifikatsdialog sieht.

Häufige Fragen

Kann ich für Web und Mail dasselbe Zertifikat verwenden?

Ja, wenn beide Dienste auf derselben Maschine laufen und das Zertifikat alle Hostnamen im SAN enthält. Bei getrennten Servern ist ein eigenes Zertifikat pro Server einfacher, weil sonst Dateien kopiert werden müssen.

Reicht ein selbstsigniertes Zertifikat auf dem Mailserver?

Für den Empfang von anderen Servern funktioniert es meist, weil die wenigsten prüfen. Mailclients der Kunden zeigen aber bei jedem Verbindungsaufbau eine Warnung, und mit MTA-STS oder DANE ist es unbrauchbar. Ein kostenloses Let's-Encrypt-Zertifikat ist die bessere Wahl.

Warum zeigt IMAP das neue Zertifikat, SMTP aber das alte?

Weil nur Dovecot neu geladen wurde, nicht Postfix, oder weil beide Dienste auf verschiedene Zertifikatsdateien zeigen. Prüfe die Pfade in beiden Konfigurationen und lade beide Dienste neu.