Perché un certificato self-hosted si rinnova localmente ma non dall'esterno?
Un certificato può rinnovarsi localmente ma fallire pubblicamente quando l’autorità ACME non riesce a raggiungere o verificare la challenge attraverso il percorso esposto a Internet.
Su un NAS self-hosted o su un home server, una prova locale può confermare che Certbot, acme.sh o il reverse proxy riescano a creare i file della challenge e ad accedere alla propria configurazione. Il rilascio pubblico richiede requisiti diversi: il DNS autorevole deve puntare all’indirizzo corretto, il percorso IPv4 o IPv6 selezionato deve essere raggiungibile, il router e il firewall devono inoltrare la richiesta di convalida e il reverse proxy deve servire l’esatto token della challenge prima che reindirizzamenti o percorsi dell’applicazione interferiscano.
Separa il corretto funzionamento del client locale dalla convalida pubblica del dominio
Leggi il log del rinnovo e identifica cosa ha avuto effettivamente successo. Un controllo della configurazione locale, un test di analisi del certificato, la scrittura nella webroot o una richiesta di staging non dimostrano che un’autorità di certificazione esterna abbia raggiunto il home server.
Un caso comune di Nginx Proxy Manager identifica la raggiungibilità della porta 80 pubblica come il primo requisito da verificare quando una challenge HTTP fallisce nonostante un’interfaccia proxy locale funzionante.
Annota il tipo di challenge, il nome host, l’URL di convalida, l’indirizzo risolto e l’errore esatto della CA. Procedi solo dal primo errore esterno — ricerca DNS, connessione TCP, stato HTTP, mancata corrispondenza del token o convalida secondaria — invece di forzare ripetutamente il rinnovo senza nuove informazioni.
Confronta i record A e AAAA autorevoli con il percorso reale del server
Interroga ogni nome host del certificato tramite il DNS autorevole e annota le risposte A e AAAA. Confrontale con l’attuale IPv4 pubblico del router, con l’indirizzo IPv6 raggiungibile del server e con il proxy che serve effettivamente la challenge.
Un caso di rinnovo su Virtualmin è andato a buon fine solo dopo la rimozione di un record AAAA pubblicato che inviava la convalida verso un percorso IPv6 non funzionante, dimostrando come un percorso di convalida AAAA non funzionante possa avere la precedenza su una configurazione IPv4 altrimenti sana.
Se una famiglia di indirizzi non è completamente raggiungibile, rimuovi temporaneamente quel record oppure correggi il relativo firewall, instradamento, listener e percorso del proxy. Verifica inoltre che tutti i nameserver autorevoli restituiscano gli stessi record aggiornati prima di riprovare il rilascio.
Testa l’URL esatto della challenge HTTP dall’esterno della rete domestica
Per HTTP-01, inserisci un file di test innocuo nel percorso /.well-known/acme-challenge/ configurato e richiedilo tramite HTTP da una rete mobile o da un’altra rete esterna utilizzando il nome host del certificato.
Una segnalazione relativa al self-hosting di Home Assistant mostra come una challenge HTTP bloccata dall’ISP impedisca la convalida HTTP anche quando il servizio funziona localmente.
La richiesta esterna deve raggiungere il token corretto senza autenticazione, una pagina captive, una schermata di accesso del router, un errore 404 dell’applicazione o un reindirizzamento verso una destinazione non raggiungibile. Se la porta TCP 80 non si apre mai, controlla l’ISP, il CGNAT, il port forwarding del router, il firewall dell’host e il listener del proxy prima di modificare il client ACME.
Verifica che il reverse proxy e la webroot servano lo stesso token
Confronta il percorso del token scritto dal client ACME con il filesystem o il responder temporaneo utilizzato dall’host virtuale pubblico. Container, bind mount e reti proxy separate possono fare in modo che il client scriva in una directory mentre NGINX o Caddy ne servono un’altra.
Controlla il log degli accessi del proxy durante una singola richiesta di challenge esterna. Una richiesta che arriva ma restituisce 404 indica una mancata corrispondenza tra percorso e webroot; il codice 401 o 403 indica autenticazione o filtraggio; il codice 502 indica una dipendenza upstream non necessaria nel percorso della challenge.
Dai alla posizione della challenge la priorità rispetto al normale routing dell’applicazione e conserva il nome host. Mantieni semplici i reindirizzamenti e verificali esternamente; non inviare il token attraverso un’applicazione backend che potrebbe essere offline durante il rinnovo.
Controlla CGNAT, firewall e raggiungibilità da più posizioni
Confronta l’indirizzo WAN del router con l’indirizzo IPv4 pubblico e conferma che la porta di convalida sia raggiungibile da più di una rete esterna. Un test locale del NAT loopback può avere esito positivo anche quando il traffico Internet non sollecitato non raggiunge mai il router.
Le autorità di certificazione convalidano sempre più spesso da più posizioni di rete per ridurre gli attacchi di routing. La ricerca sui punti di osservazione per la convalida multipla spiega perché un percorso raggiungibile da un solo Paese, ISP o servizio di test possa comunque fallire una convalida più ampia.
Rimuovi il geoblocking, i filtri per Paese, le regole di rifiuto temporanee e i limiti di frequenza dal percorso ristretto della challenge durante la convalida. Se la connessione domestica è dietro CGNAT o l’ISP blocca la porta richiesta, usa DNS-01 o un metodo di convalida in uscita invece di indebolire regole del firewall non correlate.
Scegli il tipo di challenge adatto al confine di rete
Mantieni HTTP-01 quando il DNS pubblico è corretto e la porta 80 può raggiungere in modo affidabile il responder della challenge. Usa DNS-01 quando la raggiungibilità in ingresso non è disponibile, sono necessari certificati wildcard o il servizio deve rimanere privato.
L’articolo di ZimaSpace su come il CGNAT blocchi la convalida in ingresso aiuta a capire quando sia più appropriato cambiare il metodo ACME invece di riparare il proxy locale.
La correzione è completa solo quando un rinnovo forzato ha esito positivo tramite la CA di produzione, il nuovo certificato viene distribuito al proxy attivo, i client esterni ricevono il nuovo numero di serie e la nuova data di scadenza e un test di rinnovo automatico funziona senza modifiche manuali alle porte o al DNS.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
