Behebung des Zimbra-Administrationskonsolenfehlers 404 (Nicht gefunden) nach SSL-Erneuerung

Beispiel (kein realer Vorfall): Jordan administriert einen fiktiven Zimbra-Server mail.example.com. Nach der Erneuerung des SSL/TLS-Zertifikats öffnet Jordan ein gespeichertes Lesezeichen der Admin-Konsole und erhält die Fehlermeldung „404 Not Found“. Die Erneuerung könnte damit zusammenhängen, aber ein 404-Fehler allein beweist nicht, dass das Zertifikat ungültig ist. Möglicherweise verwendet die Adresse den falschen Port, Proxy, Hostnamen oder die falsche URL-Route.

In diesem Beispiel empfiehlt Jordan folgende Vorgehensweise: Bestätigen Sie die gewünschte URL der Admin-Konsole, testen Sie die direkten und die über den Proxy geleiteten Endpunkte separat, prüfen Sie den Status des Zimbra-Dienstes und die bereitgestellten Zertifikate und starten Sie eine Komponente erst dann neu, wenn dies angezeigt wird. Beachten Sie die versionsspezifischen Anweisungen Ihrer Installation: Die Vorgehensweise bei Zimbra-Ports und Zertifikaten kann je nach Version und verwendetem Server (Zimbra Proxy, separater Load Balancer oder externer Reverse-Proxy) variieren.

Was bedeutet ein 404-Fehler nach der SSL-Zertifikatserneuerung?

Eine explizite HTTP-404-Antwort eines Browsers bedeutet in der Regel, dass ein HTTP-Server die Anfrage beantwortet, aber keine passende Ressource oder Route gefunden hat. Daher sind Hostname, Port, URL-Pfad, virtueller Host und Proxy-Route wichtige Prüfpunkte. Dies unterscheidet sich von einer Browser-Zertifikatswarnung oder einem TLS-Handshake-Fehler. Allerdings kann auch ein Reverse-Proxy oder eine Web Application Firewall (WAF) selbst einen 404-Fehler zurückgeben, wenn Host oder Route nicht übereinstimmen. Der Status allein gibt also nicht an, welche Schicht verantwortlich ist.

Zimbra dokumentiert die direkte Administrationskonsole 7071standardmäßig über den TCP-Port. Wenn der Zimbra-Proxy für die Administrationskonsole konfiguriert ist, lautet der dokumentierte Standard-Proxy-Port 8080. 9071Dieser ist optional und kann angepasst werden. Die Standard-Webmail-Adresse auf Port 8080 443ist nicht automatisch derselbe Endpunkt wie die direkte Administrationskonsole. Überprüfen Sie die URL-Richtlinien der Zimbra-Administrationskonsole und die Portreferenz von Zimbra anhand Ihrer Konfiguration.

Wie sollte man den Fehler beheben?

1. Bestätigen Sie die genaue Adresse der Admin-Konsole.

Verwenden Sie den für Ihre Bereitstellung konfigurierten Hostnamen und Port, anstatt anzunehmen, dass Ihre Webmail-URL auch die URL der Admin-Konsole ist. Für eine typische Direktverbindung dokumentiert Zimbra eine URL im Format `/ webmail / https://server.example.com:7071...https://proxy.example.com:9071/admin

In Jordans hypothetischem Fall verweist das alte Lesezeichen auf den öffentlichen Webmail-Hostnamen auf Port 443. Jordan würde diesen mit dem dokumentierten oder konfigurierten Admin-Endpunkt vergleichen. Ein 404-Fehler beim Webmail-Host bedeutet nicht zwangsläufig, dass die Zimbra-Administrationskonsole selbst nicht erreichbar ist. Falls Port 7071 absichtlich für das öffentliche Internet gesperrt ist, testen Sie ihn nur von einem autorisierten Netzwerk oder lokal; öffnen Sie ihn nicht öffentlich zu Testzwecken. Die Zimbra-Proxy-Richtlinien empfehlen, den direkten Zugriff auf Port 7071 einzuschränken, wenn Administratoren den Proxy-Endpunkt verwenden.

2. Vergleichen Sie die direkten und die Proxy-Routen.

Testen Sie die Routen nacheinander mit dem korrekten Hostnamen, Schema und Port. Funktioniert der direkte Zugriff auf Port 7071 aus einem zulässigen Netzwerk, die Proxy-Route auf Port 9071 liefert jedoch den Fehlercode 404, überprüfen Sie die Konfiguration der Proxy-Administrationskonsole und das Hostnamen-Routing. Schlägt auch die direkte Route fehl, prüfen Sie den Mailbox-Server und das für den zugehörigen Administrationskonsolendienst bereitgestellte Zertifikat. Funktionieren beide Zimbra-Routen, die öffentliche URL liefert aber weiterhin den Fehlercode 404, untersuchen Sie den externen Load Balancer, Reverse-Proxy, das CDN oder die Web Application Firewall vor Zimbra.

Nutzen Sie diesen Vergleich zur Diagnose, nicht als Befehl zur Aktivierung neuer Netzwerkzugriffe. Ein blockierter direkter Port kann eine beabsichtigte Sicherheitsmaßnahme sein. Die Einrichtungsanleitung für den Zimbra-Administrationskonsolen-Proxy beschreibt den optionalen Listener auf Port 9071 und weist darauf hin, dass die Administrationskonsole des Mailbox-Servers normalerweise auf Port 7071 verbleibt.

3. Überprüfen Sie die Zimbra-Dienste und Proxy-Protokolle.

Melden Sie sich mit dem für Ihre Installation geeigneten Administratorkonto am Zimbra-Host an und überprüfen Sie anschließend den Dienststatus. Die folgenden Statusbefehle sind schreibgeschützt:

su - zimbra
zmcontrol status
zmproxyctl status

zmcontrol statusDieser Befehl meldet den Status der Zimbra-Komponente. zmproxyctl statusEr ist hilfreich, wenn Zimbra Proxy installiert ist. Ist der Befehl nicht verfügbar oder Ihre Topologie keinen Zimbra Proxy, überspringen Sie ihn und überprüfen Sie die Komponente, die die URL tatsächlich bereitstellt. Eine gestoppte Mailbox- oder Proxy-Komponente kann einen Fehler beim Weiterleiten einer URL verursachen. Starten Sie jedoch nicht den gesamten Server neu, nur weil eine URL den Statuscode 404 zurückgibt.

Bei einer Proxy-Anfrage identifiziert Zimbra /opt/zimbra/log/nginx.access.logdie /opt/zimbra/log/nginx.logentsprechenden Proxy-Logs. Vergleichen Sie Anfragezeitpunkt und angeforderten Host/Pfad mit der dort aufgezeichneten Antwort. Falls die Anfrage nicht in den Zimbra-Proxy-Logs erscheint, stammt der 404-Fehler möglicherweise von einem vorgelagerten Load Balancer oder einem anderen Frontend-Dienst. Weitere Informationen finden Sie im Zimbra Proxy Guide, insbesondere im Abschnitt zur Fehlerbehebung .

4. Überprüfen Sie, welches Zertifikat jeder Endpunkt vorlegt.

Ein auf der Festplatte erneuertes Zertifikat ist nicht unbedingt dasselbe Zertifikat, das aktuell von jedem Zimbra-Dienst geladen wird. Führen Sie auf dem Zimbra-Host die Prüfung des bereitgestellten Zertifikats des Zertifikatmanagers mit der von Ihrer installierten Version unterstützten Syntax aus:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Überprüfen Sie die Zertifikatsdetails des Dienstes, der die fehlerhafte Route verarbeitet, einschließlich Gültigkeitsdaten und Hostname bzw. alternativer Antragstellernamen. Wenn der Browser Port 443 über einen externen TLS-Terminator erreicht, überprüfen Sie auch dort das Zertifikat und die Routing-Konfiguration; Zimbra ist möglicherweise nicht die Komponente, die dieses öffentliche Zertifikat präsentiert. Überprüfen Sie in einer Multi-Server-Umgebung die relevanten Proxy- und Mailbox-Knoten. Zimbra weist darauf hin, dass viewdeployedcrtder lokale Server gemeldet wird; eine Überprüfung auf einem Knoten beweist daher nicht, dass jeder Knoten über das erneuerte Zertifikat verfügt.

Wenn das korrekte Zertifikat bereitgestellt ist und das einzige Symptom ein HTTP-404-Fehler ist, untersuchen Sie den Pfad und das Proxy-Routing weiter, anstatt das Zertifikat wiederholt zu erneuern. Wenn das bereitgestellte Zertifikat veraltet, ungültig oder nicht mit dem privaten Schlüssel oder der Zertifikatskette kompatibel ist, folgen Sie dem für Ihre Zimbra-Version beschriebenen Zertifikatbereitstellungspfad.

5. Ein Zertifikat sollte nur dann erneut bereitgestellt werden, wenn die Prüfung anzeigt, dass dies erforderlich ist.

Bevor Sie Zertifikate ändern, vergewissern Sie sich, dass Sie den passenden privaten Schlüssel, das erneuerte Serverzertifikat und die vollständige Zertifikatskette Ihres Anbieters besitzen. Bewahren Sie den privaten Schlüssel sicher auf. In Jordans fiktivem Beispiel heißen die Dateien commercial.key, commercial.crt, und ca_chain.crt; ersetzen Sie diese durch die tatsächlichen Pfade auf Ihrem Server. Die unten aufgeführten Dateinamen sind Beispiele und werden nicht automatisch von Zimbra erstellt.

Bei kommerziellen Zertifikaten dokumentiert Zimbra die Überprüfung, ob das Zertifikat vor der Bereitstellung mit Schlüssel und Zertifikatskette übereinstimmt. Passen Sie den Befehl an Ihre Pfade und die für Ihre Version erforderlichen Benutzerberechtigungen an.

/opt/zimbra/bin/zmcertmgr verifycrt comm \
  /opt/zimbra/ssl/zimbra/commercial/commercial.key \
  /tmp/commercial.crt \
  /tmp/ca_chain.crt

Fahren Sie nur fort, wenn die Überprüfung bestätigt, dass der Schlüssel übereinstimmt und die Zertifikatskette gültig ist. Schlägt die Überprüfung fehl, brechen Sie den Vorgang ab und korrigieren Sie den Schlüssel, das Zertifikat oder die Zwischenzertifikatskette. Verwenden Sie kein nicht übereinstimmendes Zertifikat, um zu prüfen, ob dadurch ein 404-Fehler behoben wird.

Bei erfolgreicher Verifizierung sieht das dokumentierte Muster für die Bereitstellung kommerzieller Zertifikate wie folgt aus:

/opt/zimbra/bin/zmcertmgr deploycrt comm \
  /tmp/commercial.crt \
  /tmp/ca_chain.crt

Diese Befehle sind keine allgemeingültigen Anweisungen zur Zertifikatserneuerung. Die Dokumentation des Zimbra-Zertifikats enthält versionsspezifische Hinweise zu Berechtigungen. Bei einer Bereitstellung auf mehreren Knoten muss das Zertifikat auf den Knoten installiert und verifiziert werden, die den relevanten Datenverkehr verarbeiten. Lesen Sie die Dokumentation der Administrationskonsole und der CLI-Zertifikatstools sowie, bei einer Let's Encrypt-basierten Einrichtung, die aktuellen Anweisungen für das Zimbra Let's Encrypt-Zertifikat . Kopieren Sie keine Befehle aus einer älteren Version, ohne sie vorher mit Ihrer installierten Version abzugleichen.

6. Starten Sie den betroffenen Dienst neu und testen Sie anschließend beide Endpunkte.

Die Hinweise zur Zertifikatsbereitstellung von Zimbra fordern einen Neustart der Dienste, damit diese das neue Zertifikat laden. Wählen Sie den minimalen Neustart, der von Ihrer Topologie und Version unterstützt wird. Falls nur das Zimbra-Proxy-Zertifikat oder die generierte Proxy-Konfiguration neu geladen werden muss, lautet der Befehl für den Proxy-Dienst:

zmproxyctl restart

Ein vollständiger zmcontrol restartNeustart betrifft die Zimbra-Dienste auf dem betroffenen Host und kann den E-Mail-Zugriff unterbrechen. Führen Sie ihn während eines Wartungsfensters durch, wenn die Zertifikatsbereitstellung für Ihre Version dies erfordert, und planen Sie dies für jeden betroffenen Knoten ein. Die Zimbra-Zertifikatsanleitung beschreibt einen vollständigen Neustart der Dienste im Zusammenhang mit kommerziellen Zertifikaten für einzelne Server; die Proxy-Anleitung erklärt, dass ein Proxy-Neustart die Proxy-Konfiguration neu generiert, bevor der Proxy wieder gestartet wird. Führen Sie nicht beide Neustartpfade automatisch aus.

Nachdem der ausgewählte Dienst wieder verfügbar ist, testen Sie dieselben URLs erneut: zuerst die vorgesehene direkte oder Proxy-Adresse der Admin-Konsole aus einem autorisierten Netzwerk, dann die öffentliche oder per Load Balancer verteilte URL. Vergewissern Sie sich, dass die erwartete Anmeldeseite geladen wird, der Browser das aktualisierte Zertifikat für den Hostnamen anzeigt und die entsprechenden Protokolle keinen Routen- oder Upstream-Fehler mehr für diese Anfrage anzeigen. In Jordans fiktivem Beispiel wird geprüft, ob das gespeicherte Lesezeichen nun auf den konfigurierten Endpunkt verweist – nicht, ob ein erfundenes Testergebnis erzielt wurde.

Wann sollte man außerhalb von Zimbra ermitteln?

Wenn sowohl die direkten als auch die konfigurierten Proxy-Endpunkte von Zimbra korrekt antworten, die öffentliche URL aber weiterhin den Fehler 404 zurückgibt, liegt die Ursache wahrscheinlich in einem externen Frontend oder dessen Virtual-Host-Regel. Überprüfen Sie den Upstream-Hostnamen und -Port, die TLS-Terminierungseinstellungen, den weitergeleiteten Host-Header und die URL-Rewrite-Regeln des Reverse-Proxys. Falls das öffentliche Zertifikat außerhalb von Zimbra endet, reicht die alleinige Erneuerung des internen Zertifikats von Zimbra nicht aus, um den externen Listener zu aktualisieren.

Vergleichen Sie bei einer Antwort des Zimbra-Proxys den Zeitstempel und den Status nginx.access.logmit den Details in den Protokollen nginx.log. Fehlt eine Antwort in diesen Protokollen, überprüfen Sie den externen Proxy oder Load Balancer. Bearbeiten Sie die generierten Zimbra-NGINX-Dateien nicht direkt; der Zimbra-Proxy-Dienst generiert seine Konfiguration beim Neustart neu. Daher sollten dauerhafte Änderungen gemäß den für die installierte Version unterstützten Proxy-Konfigurationsmethoden vorgenommen werden.

Woran erkennt man, dass die Reparatur abgeschlossen ist?

• Das Lesezeichen verwendet den konfigurierten Hostnamen, das Schema, den Port und die Route.
• Der vorgesehene Endpunkt der Admin-Konsole antwortet aus einem autorisierten Netzwerk; ein absichtlich blockierter direkter Port bleibt blockiert.
• Die relevanten Dienste von Zimbra melden, dass sie laufen, und das bereitgestellte Zertifikat stimmt mit dem Hostnamen und der aktuellen Gültigkeitsdauer überein.
• Der Proxy oder das externe Frontend liefert die erwartete Admin-Konsolenseite anstelle eines 404-Fehlers.
• Aus den Protokollen geht hervor, dass die Anfrage die erwartete Komponente erreicht hat und kein anderer Knoten mehr das alte Zertifikat verwendet.

Die für diesen Leitfaden herangezogene offizielle Zimbra-Dokumentation nennt 7071 als Standardport für die direkte Admin-Konsole und 9071 als optionalen Proxy-Port. Da ein 404-Fehler auf verschiedenen Ebenen auftreten kann, verwenden Sie diese Standardwerte als Anhaltspunkte für die Diagnose und überprüfen Sie die tatsächlichen Werte in Ihrer Zimbra-Version und -Topologie.

Offizielle Referenzen

• Zimbra-Administrationskonsole
• Zimbra-Häfen
• Aktivierung des Admin-Konsolen-Proxys
• Zimbra Proxy-Leitfaden
• Administrationskonsole und CLI-Zertifikatstools
• Installation eines Let's Encrypt SSL-Zertifikats