Caddy e Cloudflare DNS-01: diagnosticare un wildcard scaduto

Quando un certificato wildcard gestito da Caddy scade, controllerei prima quale certificato riceve il client. Poi ricostruirei il percorso di rinnovo: processo in esecuzione, modulo DNS, credenziali, scrittura del record e validazione ACME.

Un servizio attivo non dimostra che il rinnovo stia riuscendo. Allo stesso modo, un certificato nuovo presente su disco non dimostra che sia quello servito al browser: in mezzo possono esserci altri proxy o un endpoint diverso.

Identificare l’endpoint TLS che sta rispondendo

Apri il sito dal percorso su cui si verifica l’errore e osserva nome, emittente e scadenza del certificato. Se il dominio passa da Cloudflare, distingui il certificato esposto dall’edge da quello dell’origine. Una verifica da dentro la rete può raggiungere un percorso diverso da quello pubblico.

Per leggere il certificato di un endpoint specifico puoi usare OpenSSL. Nell’esempio, sostituisci indirizzo e nome; il parametro SNI deve restare il nome del servizio:

openssl s_client -connect 192.0.2.10:443 -servername app.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer -subject

Questo comando ispeziona il certificato presentato: non è da solo una verifica completa della fiducia, del nome e dell’intera catena. Annota il risultato insieme all’indirizzo raggiunto, così da confrontare lo stesso endpoint dopo l’intervento.

Verificare il binario usato dal servizio

Il modulo Cloudflare per Caddy non fa parte della distribuzione standard. Avere un eseguibile personalizzato sul disco non basta se systemd ne avvia un altro.

Controlla i comandi effettivi della unit:

systemctl show caddy -p ExecStart -p ExecReload

Esegui list-modules con il percorso del binario individuato e cerca dns.providers.cloudflare. Confronta anche la procedura di aggiornamento: quale pacchetto o build sostituisce quel file? La guida al servizio Caddy aiuta a controllare unit, utente e configurazione.

Se manca il modulo, prepara una build compatibile e valida la configurazione prima di sostituire il processo. Non assumere che un successo ottenuto con il comando caddy della shell descriva il servizio già avviato.

Controllare token e ambiente senza esporli

Il README del provider Cloudflare specifica i permessi necessari: lettura della zona e modifica DNS, limitati alle zone richieste. Il token deve essere disponibile al processo Caddy, non soltanto alla shell dell’amministratore.

Una configurazione illustrativa per un wildcard è:

*.lab.example.com {
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }
    reverse_proxy 127.0.0.1:8080
}

Qui tutti i nomi intercettati vengono indirizzati allo stesso upstream: per servizi diversi occorrono regole di routing appropriate. La variabile deve arrivare da un ambiente protetto. Non inserire il token nel repository o nei comandi condivisi; quando confronti ambienti, verifica la presenza del valore senza stamparlo.

Leggere l’errore della challenge, non indovinare la causa

Nei log cerca il tentativo relativo al nome interessato. Distingui errori API, zona non trovata, permessi, timeout e mancata visibilità del TXT. Controlla quali DNS sono autorevoli e se esiste una delega della challenge: osservare il pannello di una zona diversa non prova che il validatore trovi il record.

Let’s Encrypt usa DNS-01 anche per i wildcard. La verifica riguarda un record DNS e non richiede di esporre le porte dell’applicazione all’autorità. Questo non decide però chi può accedere al servizio una volta ottenuto il certificato.

*.lab.example.com copre un livello come app.lab.example.com, non il nome lab.example.com né x.app.lab.example.com. Controlla i nomi necessari prima di inseguire un presunto errore di rinnovo.

Monitorare il risultato servito

Dopo la correzione ripeti il controllo dall’endpoint iniziale e verifica i log. L’automazione HTTPS di Caddy gestisce emissione e rinnovo; per esperimenti ripetuti usa l’ambiente ACME di staging previsto dalla documentazione, evitando di consumare inutilmente i limiti di produzione.

Affiancherei ai log un controllo esterno della scadenza e della validità del certificato servito, con un destinatario degli alert definito. La soglia va scelta in base al ciclo dei certificati e al tempo di intervento, senza assumere per sempre la stessa durata. Il controllo deve fallire anche quando l’endpoint non è raggiungibile.