Waarom wordt een zelfgehost certificaat lokaal vernieuwd, maar mislukt dit vanaf internet?

Een certificaat kan lokaal worden vernieuwd en toch publiekelijk mislukken wanneer de ACME-autoriteit de challenge niet via het internetgerichte pad kan bereiken of verifiëren.

Op een zelfgehoste NAS of thuisserver kan een lokale test bevestigen dat Certbot, acme.sh of de reverse proxy challengebestanden kan aanmaken en de eigen configuratie kan benaderen. Publieke uitgifte stelt andere eisen: autoritatieve DNS moet naar het juiste adres verwijzen, het geselecteerde IPv4- of IPv6-pad moet bereikbaar zijn, de router en firewall moeten het validatieverzoek doorsturen en de reverse proxy moet het exacte challenge-token aanbieden voordat omleidingen of applicatieroutes tussenbeide komen.

Scheid lokaal clientsucces van publieke domeinvalidatie

Lees het vernieuwingslogboek en bepaal wat er daadwerkelijk is geslaagd. Een lokale configuratiecontrole, test voor het parseren van certificaten, schrijven naar de webroot of stagingaanvraag bewijst niet dat een externe certificaatautoriteit de thuisserver heeft bereikt.

Een veelvoorkomende Nginx Proxy Manager-situatie wijst bereikbaarheid van publieke poort 80 aan als de eerste vereiste die moet worden gecontroleerd wanneer een HTTP-challenge mislukt ondanks een lokaal werkende proxy-interface.

Noteer het type challenge, de hostnaam, de validatie-URL, het opgeloste adres en de exacte foutmelding van de certificaatautoriteit. Ga alleen verder vanaf de eerste externe fout—DNS-opzoeking, TCP-verbinding, HTTP-status, tokenfout of secundaire validatie—in plaats van de vernieuwing herhaaldelijk te forceren zonder nieuwe aanwijzingen.

Vergelijk autoritatieve A- en AAAA-records met het werkelijke serverpad

Vraag elke certificaathostnaam op via autoritatieve DNS en noteer de A- en AAAA-antwoorden. Vergelijk deze met het huidige publieke IPv4-adres van de router, het bereikbare IPv6-adres van de server en de proxy die de challenge daadwerkelijk aanbiedt.

Een Virtualmin-vernieuwingscasus slaagde pas nadat een gepubliceerd AAAA-record was verwijderd dat de validatie naar een defect IPv6-pad stuurde. Dit laat zien hoe een defect AAAA-validatiepad een verder gezonde IPv4-configuratie kan overschrijven.

Als een adresfamilie niet volledig bereikbaar is, verwijder dat record dan tijdelijk of herstel de firewall-, routerings-, listener- en proxyroutes. Controleer ook of alle autoritatieve nameservers dezelfde actuele records teruggeven voordat je de uitgifte opnieuw probeert.

Test de exacte HTTP-challenge-URL van buiten het thuisnetwerk

Maak voor HTTP-01 een onschadelijk testbestand aan onder het geconfigureerde pad /.well-known/acme-challenge/ en vraag dit vanaf mobiele data of een ander extern netwerk op via HTTP, met de certificaathostnaam.

Een rapport over zelfhosting met Home Assistant laat zien hoe een door de ISP geblokkeerde HTTP-challenge HTTP-validatie verhindert, zelfs wanneer de service lokaal werkt.

Het externe verzoek moet het juiste token bereiken zonder authenticatie, captiveportalpagina, routerlogin, 404-fout van de applicatie of omleiding naar een onbereikbare bestemming. Als TCP-poort 80 nooit opent, controleer dan de ISP, CGNAT, port forwarding op de router, de firewall van de host en de proxyluisteraar voordat je de ACME-client aanpast.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controleer of de reverse proxy en webroot hetzelfde token aanbieden

Vergelijk het tokenpad dat door de ACME-client wordt geschreven met het bestandssysteem of de tijdelijke responder die door de publieke virtuele host wordt gebruikt. Containers, bind mounts en afzonderlijke proxynetwerken kunnen ervoor zorgen dat de client naar de ene map schrijft terwijl NGINX of Caddy een andere map aanbiedt.

Bekijk het toegangslogboek van de proxy tijdens één extern challengeverzoek. Een verzoek dat aankomt maar een 404 retourneert, wijst op een verschil tussen route en webroot; 401 of 403 wijst op authenticatie of filtering; 502 wijst op een onnodige afhankelijkheid van een upstream in het challengepad.

Geef de challenge-locatie voorrang boven normale applicatieroutering en behoud de hostnaam. Houd omleidingen eenvoudig en controleer ze extern; stuur het token niet door een backendapplicatie die tijdens de vernieuwing offline kan zijn.

Controleer CGNAT, firewalls en bereikbaarheid vanaf meerdere locaties

Vergelijk het WAN-adres van de router met het publieke IPv4-adres en bevestig dat de validatiepoort bereikbaar is vanaf meer dan één extern netwerk. Een lokale NAT-loopbacktest kan slagen terwijl ongevraagd internetverkeer de router nooit bereikt.

Certificaatautoriteiten valideren steeds vaker vanaf meerdere netwerklocaties om routeringsaanvallen te beperken. Onderzoek naar meerdere validatiepunten legt uit waarom een pad dat bereikbaar is vanuit één land, ISP of testdienst toch kan falen bij bredere validatie.

Verwijder geoblocking, landfilters, tijdelijke blokkeerregels en snelheidslimieten uit het beperkte challengepad tijdens de validatie. Als de thuisverbinding achter CGNAT zit of de ISP de vereiste poort blokkeert, gebruik dan DNS-01 of een ontwerp voor uitgaande validatie in plaats van niet-gerelateerde firewallregels te verzwakken.

Kies het type challenge dat past bij de netwerkgrens

Gebruik HTTP-01 wanneer de publieke DNS correct is en poort 80 de challenge-responder betrouwbaar kan bereiken. Gebruik DNS-01 wanneer inkomende bereikbaarheid niet beschikbaar is, wildcardcertificaten vereist zijn of de service privé moet blijven.

Het ZimaSpace-artikel over hoe CGNAT inkomende validatie blokkeert helpt vaststellen wanneer het verstandiger is om de ACME-methode te wijzigen dan de lokale proxy te herstellen.

De oplossing is pas compleet wanneer een geforceerde vernieuwing via de productie-CA slaagt, het nieuwe certificaat op de actieve proxy wordt geïnstalleerd, externe clients het nieuwe serienummer en de nieuwe vervaldatum ontvangen en een test van de automatische vernieuwing werkt zonder handmatige wijzigingen aan poorten of DNS.