Zimbra-Zertifikat abgelaufen reparieren: Selbstsignierte Zertifikate sicher erneuern

Ein Zimbra-Server kann fehlerfrei erscheinen, bis Benutzer plötzlich eine Browserwarnung wie „Zertifikat abgelaufen“ erhalten, E-Mail-Clients eine SSL/TLS-Verbindung ablehnen oder ein Administrator feststellt, dass das Zertifikat abgelaufen ist. Die schnellste und sicherste Reaktion besteht darin, nicht sofort alle Zertifikatskomponenten zu ersetzen. Ermitteln Sie zunächst, welche Komponenten abgelaufen sind, und erneuern Sie dann nur die kleinste notwendige Komponente.

Das aktuelle Verfahren im Zimbra Tech Center für die Bereitstellung eines selbstsignierten Zertifikats auf einem einzelnen Server dient zmcertmgrder Erstellung und Bereitstellung von Zertifikaten. Wichtig ist, dass Zimbra darauf hinweist, dass die Erstellung einer neuen Zertifizierungsstelle (CA) für eine normale Erneuerung eines selbstsignierten Zertifikats optional ist; die CA muss nicht jedes Mal ersetzt werden, wenn das Serverzertifikat abläuft. Die für diese Anleitung verwendeten offiziellen Referenzen wurden am 6. Oktober 2026 geprüft: „ Selbstsigniertes SSL-Zertifikat neu generieren – Einzelserver und Zertifikatstools für die Verwaltungskonsole und die Befehlszeile“ .

Warum ein abgelaufenes Zimbra-Zertifikat echte Serviceprobleme verursacht

Zimbra verwendet TLS-Zertifikate für verschiedene Dienste wie Webinterface, Proxy, LDAP und E-Mail-Protokolle. Sobald ein Zertifikat abgelaufen ist, können Clients die Verbindung ablehnen, obwohl die zugrunde liegenden Zimbra-Prozesse weiterhin ausgeführt werden. Eine Browserwarnung ist daher nur ein Symptom. Abhängig von Ihrer Netzwerkarchitektur und den Client-Richtlinien können auch fehlgeschlagene sichere IMAP/POP/SMTP-Verbindungen, Proxy-Fehler oder LDAP/TLS-Probleme auftreten.

Es sind zwei verschiedene Ablauffälle zu unterscheiden:

• Lediglich das Serverzertifikat ist abgelaufen. Dies ist der einfachere Fall. Behalten Sie die bestehende Zimbra-CA bei, sofern sie noch gültig ist, generieren Sie ein neues Serverzertifikat, stellen Sie es bereit und starten Sie die Dienste neu.
• Die Zimbra-Zertifizierungsstelle ist abgelaufen. Erstellen und implementieren Sie die Zertifizierungsstelle neu und anschließend ein neues Serverzertifikat, das von dieser Zertifizierungsstelle signiert ist. In einer Umgebung mit mehreren Servern ist die Konsistenz der Zertifizierungsstelle auf allen Knoten wichtig. Behandeln Sie eine Umgebung mit mehreren Knoten daher nicht wie einen einzelnen Server.

Erstellen Sie vor jeder Änderung ein aktuelles Backup oder einen Snapshot, der Ihrer Umgebung entspricht. Die Zertifikatserneuerung ist normalerweise unkompliziert, aber ein Backup dient als Wiederherstellungspunkt, falls der Server ältere Anpassungen, manuell installierte Zertifikate oder eine gemischte Topologie aufweist.

Schritt 1: Bestätigen Sie, dass das eingesetzte Zertifikat tatsächlich abgelaufen ist.

Wechseln Sie zum Zimbra-Konto und überprüfen Sie das aktuell für lokale Dienste bereitgestellte Zertifikat:

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Überprüfen Sie die Gültigkeitsdaten und den Zertifikatsbetreff. Befindet sich das Zertifikat noch innerhalb seines Gültigkeitszeitraums, untersuchen Sie mögliche Hostnamenkonflikte, eine nicht vertrauenswürdige selbstsignierte Zertifizierungsstelle, ein altes Zertifikat, das noch von einem Proxy verwendet wird, oder eine falsche Server-/Clientzeit, anstatt Zertifikate unnötigerweise neu zu generieren.

Sie können auch das Zertifikat überprüfen, das ein Remote-Client tatsächlich über HTTPS empfängt: Ersetzen Sie mail.example.comdurch den Hostnamen, mit dem sich die Benutzer verbinden:

openssl s_client -connect mail.example.com:443 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Diese Fernprüfung ist nützlich, wenn viewdeployedcrtalles korrekt aussieht, Browser aber immer noch ein altes Zertifikat erkennen, da sie das über das Netzwerk präsentierte Zertifikat prüft und nicht nur die Dateien auf der Festplatte.

Schritt 2: Prüfen Sie den Status des Dienstes und entscheiden Sie, ob die Zertifizierungsstelle ebenfalls erneuert werden muss.

Bevor Sie die Zertifikate ändern, überprüfen Sie den aktuellen Status des Zimbra-Dienstes, um eine Ausgangsbasis zu haben:

zmcontrol status

Wenn nur das Serverzertifikat abgelaufen ist und die Zimbra-Zertifizierungsstelle (CA) noch gültig ist, überspringen Sie die Neuerstellung der CA und fahren Sie direkt mit den Serverzertifikatsbefehlen im nächsten Abschnitt fort. Dadurch werden Änderungen an der Vertrauenskette minimiert. In der Dokumentation zu Zimbra für Einzelserver wird ausdrücklich darauf hingewiesen, dass die Erstellung einer neuen CA optional ist und nicht bei jeder Erneuerung eines selbstsignierten Zertifikats erforderlich ist.

Wenn die Zertifizierungsstelle abgelaufen ist oder Sie einen dokumentierten Grund für deren Ersetzung haben, erstellen Sie eine neue:

/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr deployca

Schritt 3: Generieren und Bereitstellen eines neuen selbstsignierten Serverzertifikats

Für eine unkomplizierte Zertifikatserneuerung auf einem einzelnen Server dokumentiert Zimbra die folgende Vorgehensweise. Das Beispiel erstellt ein Zertifikat mit einer Gültigkeit von 365 Tagen:

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365
/opt/zimbra/bin/zmcertmgr deploycrt self

Wenn Clients über mehrere DNS-Namen eine Verbindung herstellen, generieren Sie das Zertifikat mit den erforderlichen alternativen Antragstellernamen (Subject Alternative Names, SUDNs), anstatt davon auszugehen, dass der Standardhostname ausreicht. Das Zertifikatstool von Zimbra unterstützt dies -subjectAltNames. Zum Beispiel:

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365 -subjectAltNames "mail.example.com,webmail.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt self

Verwenden Sie Namen, die tatsächlich auf diesen Zimbra-Dienst verweisen und von Ihren Benutzern oder Integrationen verwendet werden. Ein Zertifikat kann zwar noch gültig sein, die Validierung kann aber dennoch fehlschlagen, wenn der angeforderte Hostname nicht durch seine Subjekt-/SAN-Werte abgedeckt ist.

Verwenden Sie dieses selbstsignierte Verfahren nicht, um versehentlich ein kommerzielles/öffentlich vertrauenswürdiges Zertifikat zu überschreiben. Wenn Ihr Server ein kommerzielles Zertifikat verwenden soll, brechen Sie hier ab und folgen Sie stattdessen der von Zimbra beschriebenen Vorgehensweise zur Bereitstellung kommerzieller Zertifikate.

Schritt 4: Überprüfen Sie die Bereitstellung, starten Sie Zimbra neu und testen Sie die Anwendung clientseitig.

Bestätigen Sie, dass Zimbra das neue Zertifikat bereitgestellt hat:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Starten Sie anschließend Zimbra neu, damit die Dienste das neue Zertifikat laden:

zmcontrol restart

Nach Abschluss des Neustarts führen Sie Folgendes aus:

zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Das gewünschte Ergebnis ist einfach: Die erwarteten Dienste laufen, und das bereitgestellte Zertifikat hat nun ein zukünftiges Ablaufdatum. Führen Sie abschließend einen Remote-OpenSSL-Test mit dem Hostnamen durch, auf den die Benutzer tatsächlich zugreifen. Dies beweist, welche Dienste nach dem Neustart im Netzwerk bereitgestellt werden.

Wenn der Browser immer noch das alte oder abgelaufene Zertifikat anzeigt

Generieren Sie nicht sofort ein neues Zertifikat. Arbeiten Sie die verbleibenden Ebenen der Reihe nach durch:

• Überprüfen Sie DNS und Hostnamen. Stellen Sie sicher, dass Sie denselben Hostnamen testen, der vom neuen Zertifikat abgedeckt wird, und den gewünschten Zimbra-Server erreichen.
• Überprüfen Sie den Proxy-Pfad. In der Dokumentation zur Fehlerbehebung bei Zimbra-Zertifikaten wird darauf hingewiesen, dass ein Proxy in manchen Fällen weiterhin ein altes Zertifikat verwenden kann. Untersuchen Sie das remote bereitgestellte Zertifikat, nicht nur die lokalen Zertifikatsdateien. Siehe Zimbra-Zertifikatfehler .
• Prüfen Sie die Vertrauenswürdigkeit der Clients. Ein erneuertes, selbstsigniertes Zertifikat kann zwar noch gültig sein, wird aber von Browsern oder E-Mail-Clients möglicherweise nicht als vertrauenswürdig eingestuft. Ablaufdatum und Vertrauenswürdigkeit sind unterschiedliche Sachverhalte.
• Überprüfen Sie die Systemzeit. Eine stark fehlerhafte Systemuhr auf dem Server oder Client kann dazu führen, dass ein ansonsten gültiges Zertifikat als ungültig oder abgelaufen angezeigt wird.
• Überprüfen Sie die Zertifizierungsstelle. Wenn das Endbenutzerzertifikat neu ist, die ausstellende Zimbra-Zertifizierungsstelle jedoch abgelaufen ist, ersetzen Sie die Zertifizierungsstelle und generieren Sie das Serverzertifikat von der neuen Zertifizierungsstelle neu.

Multi-Server-Zimbra erfordert einen anderen Betreuungsaufwand.

Bei Installationen mit mehreren Knoten verwenden Sie die Vorgehensweise für mehrere Server, anstatt die Befehle für einen einzelnen Server auf jedem Host wiederholt auszuführen. Zimbra dokumentiert die Erstellung/Bereitstellung der Zertifizierungsstelle (CA) und die anschließende Bereitstellung des selbstsignierten Zertifikats auf allen Knoten deploycrt self -allserver. Es wird jedoch darauf hingewiesen, dass viewdeployedcrtnur der lokale Server gemeldet wird. Die offizielle Referenz finden Sie unter „ Selbstsigniertes SSL-Zertifikat neu generieren – Mehrere Server“ .

Eine Nichtübereinstimmung der Zertifizierungsstellen zwischen einem LDAP-Master und Replikaten kann zu TLS- und Replikationsproblemen führen. Bei einer Topologie mit mehreren Servern überprüfen Sie die Zertifizierungsstellenkette auf jedem betroffenen Knoten und befolgen Sie die dokumentierte Bereitstellungsreihenfolge.

Selbstprüfung: So erkennen Sie, ob die Reparatur abgeschlossen ist

Bevor Sie den Vorfall abschließen, überprüfen Sie bitte Folgendes:

• zmcontrol statuszeigt an, dass die erwarteten Zimbra-Dienste ausgeführt werden.
• zmcertmgr viewdeployedcrtzeigt ein Zertifikat, dessen Ablaufdatum in der Zukunft liegt.
• Eine Remote openssl s_client-Prüfung liefert für den öffentlichen/internen Hostnamen, den die Benutzer tatsächlich verwenden, die gleichen neuen Zertifikatsdaten.
• Der Zertifikatssubjekt oder SAN deckt diesen Hostnamen ab.
• Webmail und die in Ihrer Umgebung verwendeten E-Mail-Protokolle können TLS-Verbindungen herstellen.
• Falls Sie die Zimbra-Zertifizierungsstelle absichtlich ersetzt haben, wurden Clients oder interne Systeme, die die alte Zertifizierungsstelle einbinden oder ihr vertrauen, entsprechend aktualisiert.

Bei einem routinemäßigen Ablauf eines einzelnen Serverzertifikats ist es üblicherweise am wenigsten aufwändig, eine noch gültige Zimbra-CA beizubehalten, ein neues selbstsigniertes Serverzertifikat zu erstellen, dieses bereitzustellen, die Dienste neu zu starten und das Zertifikat von außerhalb des Servers zu verifizieren. Die CA sollte nur dann ausgetauscht werden, wenn sie abgelaufen ist oder ein anderer triftiger Grund für eine Erneuerung vorliegt. Dieser Ansatz behebt den unmittelbaren Ausfall und vermeidet gleichzeitig unnötige Änderungen in der Vertrauenskette.