Varför förnyas ett egenhostat certifikat lokalt men misslyckas från internet?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Why Does a Self-Hosted Certificate Renew Locally but Fail From the Internet?

Ett certifikat kan förnyas lokalt men ändå misslyckas offentligt när ACME-utfärdaren inte kan nå eller verifiera utmaningen via den internetanslutna vägen.

På en självhostad NAS eller hemserver kan en lokal testkörning bekräfta att Certbot, acme.sh eller reverse proxyn kan skapa utmaningsfiler och komma åt sin egen konfiguration. Offentlig utfärdning innebär andra krav: auktoritativ DNS måste peka på rätt adress, den valda IPv4- eller IPv6-vägen måste vara nåbar, routern och brandväggen måste leverera valideringsbegäran och reverse proxyn måste visa den exakta utmaningstoken innan omdirigeringar eller applikationsrutter hinner störa.

Skilj lokal klientframgång från offentlig domänvalidering

Läs förnyelseloggen och identifiera vad som faktiskt lyckades. En lokal konfigurationskontroll, ett test av certifikattolkning, en skrivning till webbroten eller en staging-begäran bevisar inte att en extern certifikatutfärdare nådde hemservern.

I ett vanligt Nginx Proxy Manager-fall identifieras nåbarhet via offentlig port 80 som det första kravet att verifiera när en HTTP-utmaning misslyckas trots att det lokala proxygränssnittet fungerar.

Anteckna utmaningstyp, värdnamn, validerings-URL, upplöst adress och det exakta CA-felet. Fortsätt endast utifrån det första externa felet – DNS-uppslagning, TCP-anslutning, HTTP-status, tokenmismatch eller sekundär validering – i stället för att upprepade gånger tvinga fram en förnyelse utan nya bevis.

Jämför auktoritativa A- och AAAA-poster med den verkliga servervägen

Fråga varje certifikatvärdnamn via auktoritativ DNS och anteckna dess A- och AAAA-svar. Jämför dem med routerns aktuella offentliga IPv4-adress, serverns nåbara IPv6-adress och den proxy som faktiskt levererar utmaningen.

Ett Virtualmin-fall med förnyelse lyckades först efter att en publicerad AAAA-post som skickade valideringen till en trasig IPv6-väg hade tagits bort. Det visar hur en trasig AAAA-valideringsväg kan åsidosätta en i övrigt fungerande IPv4-konfiguration.

Om en adressfamilj inte är helt nåbar kan du tillfälligt ta bort posten eller åtgärda dess brandvägg, routing, lyssnare och proxyväg. Kontrollera också att alla auktoritativa namnservrar returnerar samma aktuella poster innan du försöker utfärda certifikatet igen.

Testa den exakta HTTP-utmanings-URL:en utifrån hemmet

För HTTP-01 placerar du en ofarlig testfil under den konfigurerade sökvägen /.well-known/acme-challenge/ och begär den via mobilnätet eller ett annat externt nätverk med certifikatvärdnamnet över HTTP.

En rapport om självhosting med Home Assistant visar hur en ISP-blockerad HTTP-utmaning förhindrar HTTP-validering även när själva tjänsten fungerar lokalt.

Den externa begäran måste nå rätt token utan autentisering, captive-sida, routerinloggning, ett applikations-404-fel eller en omdirigering till en destination som inte kan nås. Om TCP-port 80 aldrig öppnas bör du kontrollera internetleverantören, CGNAT, routervidarebefordran, värdens brandvägg och proxyns lyssnare innan du ändrar ACME-klienten.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Verifiera att reverse proxyn och webbroten visar samma token

Jämför tokensökvägen som ACME-klienten skriver till med filsystemet eller den tillfälliga svarare som används av den offentliga virtuella värden. Behållare, bind-monteringar och separata proxynätverk kan göra att klienten skriver till en katalog medan NGINX eller Caddy visar en annan.

Granska proxyns åtkomstlogg under en extern utmaningsbegäran. En begäran som anländer men returnerar 404 pekar på en mismatch mellan rutt och webbroten; 401 eller 403 pekar på autentisering eller filtrering; 502 pekar på ett onödigt beroende av en backend i utmaningssökvägen.

Ge utmaningsplatsen företräde framför normal applikationsrouting och bevara värdnamnet. Håll omdirigeringarna enkla och verifiera dem externt; skicka inte token genom en backend-applikation som kan vara offline under förnyelsen.

Kontrollera CGNAT, brandväggar och nåbarhet från flera platser

Jämför routerns WAN-adress med den offentliga IPv4-adressen och bekräfta att valideringsporten kan nås från mer än ett externt nätverk. Ett lokalt NAT-loopback-test kan lyckas även när oombedd internettrafik aldrig når routern.

Certifikatutfärdare validerar i allt högre grad från flera nätverksplatser för att minska routingattacker. Forskning om validering från flera vantage points förklarar varför en väg som kan nås från ett land, en internetleverantör eller en testtjänst ändå kan misslyckas vid bredare validering.

Ta bort geoblockering, landsfilter, tillfälliga nekanderegler och hastighetsbegränsningar från den begränsade utmaningssökvägen under valideringen. Om hemanslutningen ligger bakom CGNAT eller internetleverantören blockerar den nödvändiga porten bör du använda DNS-01 eller en utgående valideringslösning i stället för att försvaga orelaterade brandväggsregler.

Välj den utmaningstyp som passar nätverksgränsen

Behåll HTTP-01 när offentlig DNS är korrekt och port 80 på ett tillförlitligt sätt kan nå utmaningssvararen. Använd DNS-01 när inkommande nåbarhet saknas, när wildcard-certifikat krävs eller när tjänsten måste förbli privat.

ZimaSpace-artikeln om hur CGNAT blockerar inkommande validering hjälper dig att avgöra när det är lämpligare att byta ACME-metod än att reparera den lokala proxyn.

Åtgärden är klar först när en tvingad förnyelse lyckas via produktions-CA:n, det nya certifikatet har distribuerats till den aktiva proxyn, externa klienter får det nya serienumret och utgångsdatumet och ett obevakat förnyelsetest fungerar utan manuella port- eller DNS-ändringar.