SSL-Zertifikatsfehler bei Mail-Servern beheben: Ein Praxisfall mit Sectigo-Zertifikaten

Kürzlich bin ich auf ein klassisches, aber tückisches Problem gestoßen: Ein Mail-Server mit scheinbar gültigem SSL-Zertifikat warf dennoch Verifikationsfehler. In diesem Beitrag teile ich die Lösung für das Problem der unvollständigen Zertifikatskette – ein Fehler, der häufiger auftritt als man denkt.

Das Problem: Vertrauenswürdige Zertifikate, die nicht vertraut werden

Beim Testen einer IMAP-Verbindung mit OpenSSL tauchten folgende Fehlermeldungen auf:

openssl s_client -connect host.meinserver.de:993

Fehlermeldungen

verify error:num=20:unable to get local issuer certificate
verify error:num=21:unable to verify the first certificate
Verify return code: 21 (unable to verify the first certificate)

Paradoxerweise zeigte der Server ein gültiges Sectigo-Zertifikat an, das noch bis Januar 2026 gültig war. Was war also das Problem?

Die Ursache: Fehlende Intermediate-Zertifikate

Das Problem lag in einer unvollständigen Zertifikatskette. Während das Server-Zertifikat korrekt installiert war, fehlte ein kritisches Zwischenzertifikat:

• ✅ Server-Zertifikat: host.meinserver.de
• ❌ FEHLEND: Sectigo RSA Domain Validation Secure Server CA
• ✅ Intermediate CA: USERTrust RSA Certification Authority
• ✅ Root CA: AAA Certificate Services

Die Analyse: Zertifikatskette verstehen

Mit folgendem Befehl kann man die aktuelle Zertifikatskette analysieren:

openssl s_client -connect domain.de:993 -showcerts

Die Ausgabe zeigt alle vom Server übertragenen Zertifikate. Im problematischen Fall sah man nur das Server-Zertifikat, aber nicht die notwendigen Intermediate-Zertifikate.

Wichtiger Hinweis: Moderne Browser verwenden oft eigene Zertifikatsspeicher und können fehlende Intermediate-Zertifikate automatisch „erraten“. Mail-Clients sind hier oft strenger und benötigen die vollständige Kette.

Die Lösung: Vollständige Zertifikatskette erstellen

Schritt 1: Backup der aktuellen Konfiguration

Wir haben unsere Zertifikate für den Server im Ordner /root/ssl gespeichert.

# Backup der aktuellen Bundle-Datei
cp /root/ssl/host.meinserver.de.bundle \
   /root/ssl/host.meinserver.de.bundle_bak_$(date +%Y%m%d)

Schritt 2: Korrekte Zertifikatskette erstellen

Die neue Bundle-Datei muss die Zertifikate in der richtigen Reihenfolge enthalten:

1. Server-Zertifikat (host.meinserver.de)
2. Intermediate CA (Sectigo RSA Domain Validation Secure Server CA)
3. Root CA (USERTrust RSA Certification Authority)
4. Cross-Root (AAA Certificate Services)

Wir haben das Zertifikat von Sectigo erhalten. Wir haben ebenfalls das fullchain.bundle erhalten.

|--host_meinserver_de
   |
   |--host_meinserver_de.ca-bundle
   |--host_meinserver_de.crt

Diese führen wir nun zusammen:

cd /root/ssl

cat host_meinserver_de.crt host_meinserver_de.ca-bundle > host_meinserver_de.pem

In unserem Fall haben wir Dovecot installiert. Hier passen wir die Config an.

Schritt 3. Dovecot Config anpassen

nano /etc/dovecot/dovecot.conf

Hier sehen wir, dass Dovecot auf die Zertifikate von Postfix zurückgreift.

ssl_cert = </etc/postfix/smtpd.cert
ssl_key = </etc/postfix/smtpd.key

Wir ersetzen dazu zuerst das Postfix Cert und den Key und erstellen einen Symlink.

cd /etc/postfix

mv smtpd.cert smtpd.cert_bak
mv smtpd.key smtpd.key_bak

ln -s /root/ssl/host_meinserver_de.crt smtpd.cert
ln -s /root/ssl/host_meinserver_de.key smtpd.key

Achtung: wir haben noch nicht das korrekte Bundle in Dovecot verlinkt. Das machen wir im nächsten Schritt. Wir kommentieren das vorhanden ssl_cert und ersetzen es durch eine neue

## Wir kommentieren die alte ssl_cert aus
#ssl_cert = </etc/postfix/smtpd.cert

## Wir ersetzen diese mit der pem aus Schritt 2
ssl_cert = </root/ssl/host_meinserver_de.pem

## Das hier bleibt
ssl_key = </etc/postfix/smtpd.key

Schritt 4: Services neustarten

# Mail-Services neustarten
systemctl restart postfix
systemctl restart dovecot

Das Ergebnis: Perfekte SSL-Verifikation

Nach der Korrektur zeigte der OpenSSL-Test folgendes Ergebnis:

Certificate chain
 0 s:CN=host.meinserver.de
 1 s:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, 
     CN=Sectigo RSA Domain Validation Secure Server CA
 2 s:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, 
     CN=USERTrust RSA Certification Authority
 3 s:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, 
     CN=AAA Certificate Services

Verification: OK
Verify return code: 0 (ok)

Best Practices für SSL-Zertifikate bei Mail-Servern

1. Vollständige Zertifikatskette verwenden

Immer die komplette Kette vom Server-Zertifikat bis zur Root-CA einbinden.

2. Regelmäßige Überprüfung

# Monatlicher Cron-Job für Zertifikatsprüfung
0 9 1 * * /usr/bin/openssl s_client -connect $(hostname):993 \
  -servername $(hostname) < /dev/null | grep "Verify return code"

3. Automatische Erneuerung einrichten

# Certbot für Let's Encrypt oder entsprechende Scripts für kommerzielle CAs
certbot renew --deploy-hook "systemctl restart postfix dovecot"

4. Multiple Protokolle testen

# IMAP SSL (993)
openssl s_client -connect domain.de:993

# SMTP SSL (465) 
openssl s_client -connect domain.de:465

# SMTP STARTTLS (587)
openssl s_client -connect domain.de:587 -starttls smtp

Troubleshooting-Checkliste

Wenn SSL-Probleme auftreten, diese Punkte abarbeiten:

•  Zertifikatsgültigkeit prüfen: openssl x509 -in cert.crt -text -noout
•  Vollständige Kette überprüfen: openssl s_client -showcerts
•  Dateiberechtigungen kontrollieren: chmod 644 *.crt && chmod 600 *.key
•  Service-Konfiguration validieren: Richtige Pfade in Postfix/Dovecot
•  Firewall/Port-Freigaben: Ports 993, 465, 587 erreichbar
•  DNS-Konfiguration: A-Records und MX-Records korrekt

Weitere hilfreiche Commands

Einige weitere Commands öiefern dir zusätzliche nützliche Infos zu deinen aktuellen Zertifikaten.

Um die Postfix Einstellungen zu testen

postconf | grep -E 'smtpd_tls_(cert|key|CApath|CAfile)'

Um die Dovecot Einstellungen zu testen

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

Fazit: Details machen den Unterschied

SSL-Zertifikatsprobleme können frustrierend sein, besonders wenn das Zertifikat selbst gültig ist. Der Schlüssel liegt oft in den Details – in diesem Fall in der vollständigen Zertifikatskette.

Die Lektion: Nicht nur das Server-Zertifikat ist wichtig, sondern die gesamte Vertrauenskette muss lückenlos vom Client zum Server übertragen werden. Mit den richtigen Tools und einem systematischen Vorgehen lassen sich solche Probleme schnell identifizieren und beheben.

Tipp für die Zukunft: Dokumentiere deine SSL-Konfiguration gut und erstelle Monitoring-Scripts, die dich rechtzeitig vor auslaufenden Zertifikaten warnen. Ein gut konfigurierter Mail-Server ist die Basis für zuverlässige E-Mail-Kommunikation.

Hast du ähnliche Probleme mit SSL-Zertifikaten erlebt? Teile deine Erfahrungen in den Kommentaren!