Oplossing voor de 404-fout 'Zimbra Admin Console niet gevonden' na SSL-vernieuwing.

Illustratief voorbeeld, geen echt incident: Jordan beheert een fictieve Zimbra-server op [adres] mail.example.com. Na het vernieuwen van het SSL/TLS-certificaat opent Jordan een opgeslagen bladwijzer in de beheerdersconsole en krijgt een "404 Not Found"-pagina te zien. De vernieuwing kan hiermee verband houden, maar een 404-fout bewijst op zichzelf niet dat het certificaat ongeldig is. Het adres kan de verkeerde poort, proxy, hostnaam of URL-route gebruiken.

In dit voorbeeld is de veiligste aanpak van Jordan om de beoogde URL van de beheerdersconsole te bevestigen, de directe en geproxyeerde eindpunten afzonderlijk te testen, de status van de Zimbra-service en de geïmplementeerde certificaten te controleren, en pas daarna een component opnieuw te implementeren of te herstarten als daar aanwijzingen voor zijn. Volg de versie-specifieke instructies van uw installatie: de procedures voor Zimbra-poorten en -certificaten kunnen per release verschillen en zijn afhankelijk van of de server gebruikmaakt van Zimbra Proxy, een aparte load balancer of een externe reverse proxy.

Wat zegt een 404-foutmelding na het verlengen van je SSL-certificaat?

Een expliciete HTTP 404-respons van een browser betekent meestal dat een HTTP-server het verzoek heeft beantwoord, maar geen overeenkomende bron of route heeft gevonden. Daarom zijn de hostnaam, poort, URL-pad, virtuele host en proxyroute belangrijke controles. Dit is iets anders dan een waarschuwing over een browsercertificaat of een mislukte TLS-handshake. Een reverse proxy of webapplicatie-firewall kan echter zelf ook een 404-foutmelding geven wanneer een host of route niet overeenkomt, dus de status alleen geeft niet aan welke laag verantwoordelijk is.

Zimbra documenteert de directe beheerdersconsole 7071standaard op TCP-poort . Als Zimbra Proxy is geconfigureerd om de beheerdersconsole te proxyen, is de gedocumenteerde standaard proxypoort 9071; deze is optioneel en kan worden aangepast. Het standaard webmailadres op poort 443is niet automatisch hetzelfde eindpunt als de directe beheerdersconsole. Controleer de URL-richtlijnen van de Zimbra-beheerdersconsole en de poortreferentie van Zimbra aan de hand van uw eigen configuratie.

Hoe moet je de fout oplossen?

1. Controleer het exacte adres van de beheerdersconsole.

Gebruik de hostnaam en poort die voor uw implementatie zijn geconfigureerd in plaats van ervan uit te gaan dat uw webmail-URL ook de URL van de beheerdersconsole is. Voor een typische directe verbinding documenteert Zimbra een URL in de vorm https://server.example.com:7071. Een beheerder die Zimbra Proxy voor de console heeft ingeschakeld, kan in plaats daarvan de hostnaam en poort van de proxy gebruiken, meestal https://proxy.example.com:9071. Voeg geen verondersteld /adminpad toe: gebruik het adres dat is opgegeven in uw installatie- of beheerdersdocumentatie.

In Jordans hypothetische geval verwijst de oude bladwijzer naar de openbare webmailhostnaam op poort 443. Jordan zou deze vergelijken met het gedocumenteerde of geconfigureerde beheerders-eindpunt. Een 404-fout op de webmailhost betekent niet dat de Zimbra-beheerconsole zelf niet beschikbaar is. Als poort 7071 opzettelijk is geblokkeerd voor het openbare internet, test deze dan alleen vanuit een geautoriseerd netwerk of lokaal; open deze niet openbaar om te testen. De proxyrichtlijnen van Zimbra raden aan om directe toegang tot poort 7071 te beperken wanneer beheerders het proxy-eindpunt gebruiken.

2. Vergelijk de directe en de proxy-routes

Test één route tegelijk met de juiste hostnaam, schema en poort. Als directe toegang via poort 7071 werkt vanuit een toegestaan ​​netwerk, maar de proxyroute via poort 9071 een 404-fout retourneert, controleer dan de configuratie van de proxy in de beheerdersconsole en de routering van hostnamen. Als de directe route ook mislukt, controleer dan de mailboxserver en het certificaat dat is geïmplementeerd in de beheerdersconsole. Als beide Zimbra-routes werken, maar de openbare URL nog steeds een 404-fout retourneert, onderzoek dan de externe load balancer, reverse proxy, CDN of webapplicatie-firewall vóór Zimbra.

Gebruik deze vergelijking als diagnostisch hulpmiddel, niet als een opdracht om nieuwe netwerktoegang in te schakelen. Een geblokkeerde directe poort kan een opzettelijke beveiligingsmaatregel zijn. De handleiding voor het instellen van de proxy in de Zimbra-beheerconsole beschrijft de optionele listener op poort 9071 en merkt op dat de beheerconsole van de mailboxserver normaal gesproken op poort 7071 blijft.

3. Controleer de Zimbra-services en proxylogboeken.

Meld u aan bij de Zimbra-host met het beheerdersaccount dat geschikt is voor uw installatie en controleer vervolgens de servicestatus. De volgende statusopdrachten zijn alleen-lezen:

su - zimbra
zmcontrol status
zmproxyctl status

zmcontrol statusDit rapport geeft de status van Zimbra-componenten weer. zmproxyctl statusHet is handig wanneer Zimbra Proxy is geïnstalleerd; als de opdracht niet beschikbaar is of als uw topologie geen Zimbra Proxy heeft, sla deze dan over en controleer de component die de URL daadwerkelijk afhandelt. Een gestopte mailbox of proxycomponent kan een mislukte route verklaren, maar herstart niet de hele server alleen omdat één URL een 404-fout retourneert.

Voor een geproxyeerde aanvraag identificeert Zimbra de aanvraagtijd /opt/zimbra/log/nginx.access.logen /opt/zimbra/log/nginx.loghet aangevraagde host-/padbestand als nuttige proxylogs. Vergelijk de aanvraagtijd en het aangevraagde host-/padbestand met het antwoord dat daarin is vastgelegd. Als de aanvraag nooit in de proxylogs van Zimbra verschijnt, kan de 404-fout afkomstig zijn van een upstream load balancer of een andere front-end service. Raadpleeg de Zimbra Proxy Guide en het gedeelte over probleemoplossing .

4. Controleer welk certificaat elk eindpunt presenteert.

Een certificaat dat op schijf is vernieuwd, is niet noodzakelijkerwijs hetzelfde certificaat dat momenteel door elke Zimbra-service wordt geladen. Voer vanaf de Zimbra-host de controle op geïmplementeerde certificaten van de certificaatbeheerder uit met behulp van de syntaxis die wordt ondersteund door uw geïnstalleerde versie:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Controleer de certificaatgegevens voor de service die de foutieve route afhandelt, inclusief de geldigheidsdatums en de hostnaam of alternatieve onderwerpnamen. Als de browser poort 443 bereikt via een externe TLS-terminator, controleer dan ook het certificaat en de routeringsconfiguratie daar; Zimbra is mogelijk niet de component die dat openbare certificaat presenteert. Controleer in een multi-serveromgeving de relevante proxy- en mailboxknooppunten. Zimbra geeft aan dat het viewdeployedcrtrapport de lokale server weergeeft, dus een controle op één knooppunt is geen bewijs dat elk knooppunt over het vernieuwde certificaat beschikt.

Als het juiste certificaat is geïmplementeerd en het enige symptoom een ​​HTTP 404-fout is, ga dan verder met het onderzoeken van het pad en de proxy-routering in plaats van het certificaat herhaaldelijk te vernieuwen. Als het geïmplementeerde certificaat verouderd, ongeldig of niet-overeenkomend is met de privésleutel of certificaatketen, volg dan de stappen voor certificaatimplementatie die specifiek zijn voor uw Zimbra-versie.

5. Herimplementeer een certificaat alleen wanneer de controle aangeeft dat dit nodig is.

Controleer voordat u certificaten wijzigt of u de bijbehorende privésleutel, het vernieuwde servercertificaat en de volledige CA-keten van uw provider hebt. Houd de privésleutel veilig. In Jordans fictieve voorbeeld heten de bestanden commercial.key, commercial.crt, en ca_chain.crt; vervang deze door de daadwerkelijke paden op uw server. De onderstaande bestandsnamen zijn voorbeelden en worden niet automatisch door Zimbra aangemaakt.

Voor een commercieel certificaat documenteert Zimbra de verificatie of het certificaat overeenkomt met de sleutel en de certificaatketen vóór de implementatie. Pas de opdracht aan uw paden en de gebruikersrechten die vereist zijn voor uw release:

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

Ga alleen verder als de verificatie-uitvoer bevestigt dat de sleutel overeenkomt en de certificaatketen geldig is. Als de verificatie mislukt, stop dan en corrigeer de sleutel, het certificaat of de tussenliggende keten. Gebruik geen certificaat met een onjuiste sleutel om te kijken of dit een 404-fout oplost.

Als de verificatie succesvol is, is het gedocumenteerde implementatiepatroon voor commerciële certificaten als volgt:

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

Deze opdrachten zijn geen universele instructies voor het verlengen van certificaten. De certificaatdocumentatie van Zimbra bevat releasespecifieke privilege-opmerkingen en een implementatie met meerdere knooppunten vereist dat het certificaat wordt geïnstalleerd en geverifieerd op de knooppunten die het relevante verkeer verwerken. Raadpleeg de certificaattools van de beheerconsole en de CLI en, voor een Let's Encrypt-gebaseerde configuratie, de actuele instructies voor Let's Encrypt-certificaten van Zimbra . Kopieer geen opdrachten van een oudere release zonder ze te controleren aan de hand van uw geïnstalleerde build.

6. Herstart de betreffende service en test vervolgens beide eindpunten.

Volgens de instructies van Zimbra voor certificaatimplementatie moeten de services opnieuw worden opgestart zodat ze het nieuwe certificaat laden. Kies de meest specifieke herstartoptie die door uw topologie en release wordt ondersteund. Als alleen het Zimbra Proxy-certificaat of de gegenereerde proxyconfiguratie opnieuw moet worden geladen, is de opdracht voor de proxyservice als volgt:

zmproxyctl restart

Een volledige zmcontrol restartherstart heeft gevolgen voor de Zimbra-services op die host en kan de toegang tot e-mail verstoren. Gebruik deze procedure tijdens een onderhoudsvenster wanneer de certificaatimplementatieprocedure voor uw versie dit vereist, en plan voor elk getroffen knooppunt. De certificaathandleiding van Zimbra beschrijft een volledige serviceherstart in de procedure voor commerciële certificaten op één server; de proxyhandleiding legt uit dat een proxyherstart de proxyconfiguratie opnieuw genereert voordat de proxy opnieuw wordt gestart. Voer niet beide herstartprocedures automatisch uit.

Nadat de geselecteerde service weer beschikbaar is, test u dezelfde URL's opnieuw: eerst het beoogde directe adres of proxy-adres van de beheerdersconsole vanuit een geautoriseerd netwerk, en vervolgens de openbare of load-balanced URL. Controleer of de verwachte inlogpagina wordt geladen, of de browser het vernieuwde certificaat voor de hostnaam weergeeft en of de relevante logboeken geen route- of upstreamfout meer tonen voor die aanvraag. In Jordans fictieve voorbeeld wordt gecontroleerd of de opgeslagen bladwijzer nu naar het geconfigureerde eindpunt verwijst, en niet of een verzonnen testresultaat is behaald.

Wanneer moet je onderzoek doen buiten Zimbra?

Als zowel de directe als de geconfigureerde proxy-eindpunten van Zimbra correct reageren, maar de openbare URL nog steeds een 404-fout retourneert, ligt de fout waarschijnlijk bij een externe front-end of de virtual-hostregel ervan. Controleer de upstream hostnaam en poort van de reverse proxy, de TLS-terminatie-instellingen, de doorgestuurde hostheader en de URL-herschrijfregels. Als het openbare certificaat buiten Zimbra eindigt, zal het vernieuwen van het interne certificaat van Zimbra alleen die externe listener niet bijwerken.

Voor een reactie die door Zimbra Proxy wordt afgehandeld, vergelijk de tijdstempel en status in nginx.access.logmet de details in nginx.log. Als een reactie niet in deze logboeken voorkomt, controleer dan de externe proxy of load balancer. Vermijd het rechtstreeks bewerken van gegenereerde Zimbra NGINX-bestanden; de proxyservice van Zimbra genereert de configuratie opnieuw bij een herstart, dus permanente wijzigingen moeten worden aangebracht volgens de ondersteunde proxyconfiguratiemethoden voor de geïnstalleerde versie.

Hoe weet je of de reparatie voltooid is?

• De bladwijzer maakt gebruik van de geconfigureerde hostnaam, het schema, de poort en de route.
• Het beoogde eindpunt van de beheerdersconsole reageert vanuit een geautoriseerd netwerk; een opzettelijk geblokkeerde directe poort blijft geblokkeerd.
• De relevante services van Zimbra melden dat ze actief zijn en dat het geïmplementeerde certificaat overeenkomt met de hostnaam en de huidige geldigheidsperiode.
• De proxy of externe front-end retourneert de verwachte beheerdersconsolepagina in plaats van een 404-fout.
• De logbestanden tonen aan dat het verzoek de verwachte component bereikt en dat geen enkel ander knooppunt het oude certificaat meer presenteert.

De officiële Zimbra-documentatie die voor deze handleiding is geraadpleegd, vermeldt 7071 als de standaardpoort voor de directe beheerdersconsole en 9071 als een optionele proxypoort voor de beheerdersconsole. Omdat een 404-fout op verschillende niveaus kan optreden, kunt u deze standaardwaarden gebruiken als diagnostische aanwijzingen en de werkelijke waarden in uw Zimbra-versie en -topologie controleren.

Officiële referenties

• Zimbra-beheerconsole
• Zimbra-havens
• De proxy in de beheerdersconsole inschakelen
• Zimbra proxy-handleiding
• Beheerconsole en CLI-certificaattools
• Een Let's Encrypt SSL-certificaat installeren