Dominio personalizzato bloccato nella convalida SSL

Hai aggiunto il record. dig lo mostra. La piattaforma continua a indicare che è in sospeso, e lo fa ormai da un'ora. Un dominio personalizzato bloccato nella convalida è esasperante proprio perché ogni verifica che puoi eseguire autonomamente sembra andare a buon fine.

Le cause sono quattro, sono tutte di natura meccanica e l'ordine riportato di seguito consente di individuarle più rapidamente.

Prima di tutto: cosa fa effettivamente la convalida

Prima che una certificate authority emetta un certificato, deve verificare che tu abbia il controllo del nome. Esistono due metodi comuni e quello usato dalla tua piattaforma determina cosa può interrompere la procedura:

• HTTP-01 — la CA richiede http://your-domain/.well-known/acme-challenge/<token> e si aspetta una stringa specifica. È necessario che le richieste HTTP non cifrate al tuo dominio raggiungano la piattaforma.
• DNS-01 — la CA cerca un record TXT. È necessario che il record esista e sia visibile al resolver della CA, che non è necessariamente quello che hai interrogato.

Quasi tutti i casi di convalida bloccata dipendono da qualcosa che si trova tra la CA e uno di questi due elementi.

Causa 1: un proxy davanti alla challenge

È la causa più comune quando il dominio si trova dietro una CDN ed è davvero difficile da diagnosticare, perché il proxy è solitamente proprio ciò che volevi usare.

Se il tuo record DNS è sottoposto a proxy invece di puntare direttamente alla piattaforma, la richiesta HTTP-01 della CA termina sul proxy. Il proxy presenta il proprio certificato, applica le proprie regole e può restituire un redirect, una pagina di challenge o un 404 — nessuno dei quali contiene il token che la CA sta aspettando.

La soluzione consiste nel consentire il passaggio della challenge:

• Disattiva il proxy (imposta il record su grey-cloud) finché il certificato non viene emesso, quindi riattivalo.
• Oppure escludi /.well-known/acme-challenge/* da qualsiasi regola di redirect o di accesso.

Il problema è che protezioni come "Always Use HTTPS" e "Under Attack" interrompono entrambe HTTP-01, anche se dal browser il sito sembra funzionare perfettamente.

Causa 2: il tipo di record errato

Due errori spiegano la maggior parte dei casi rimanenti:

Un record A che punta a un indirizzo soggetto a variazioni. Se la piattaforma ti ha fornito un hostname, usa un CNAME. Copiare l'IP attuale in un record A funziona solo finché l'indirizzo non cambia.

Un CNAME all'apice della zona. example.com non può contenere legalmente un CNAME insieme ai record SOA e NS. Alcuni provider offrono ALIAS, ANAME o il "CNAME flattening" come soluzione; altri no. Se il tuo provider non offre queste funzionalità, usa un subdomain — app.example.com — e reindirizza l'apice.

# What the world actually sees, not what your dashboard shows
dig +short app.example.com CNAME
dig +short app.example.com A

Se entrambi i comandi restituiscono una risposta vuota, per ora nient'altro in questo elenco è rilevante.

Causa 3: una propagazione che non stai misurando

dig senza argomenti interroga il tuo resolver, che potrebbe aver memorizzato in cache la risposta appena creata — o, peggio ancora, il valore NXDOMAIN precedente alla creazione del record. Una voce di cache negativa con un TTL lungo è un motivo molto comune per cui una convalida fallisce per un'ora e poi riesce senza alcun intervento.

Interroga direttamente i server authoritative e interroga un resolver pubblico per vedere ciò che probabilmente vedrà la CA:

# Ask the zone's own nameservers
dig +short app.example.com @$(dig +short NS example.com | head -1)

# Ask a resolver outside your network
dig +short app.example.com @1.1.1.1
dig +short app.example.com @8.8.8.8

Se la risposta authoritative è corretta mentre i resolver pubblici restituiscono un valore errato, devi solo attendere il TTL: non c'è nulla da correggere.

Causa 4: il CAA rifiuta l'issuer

Questo caso è raro, invisibile nei normali controlli DNS e completamente silenzioso quando si verifica.

Un record CAA sul tuo dominio indica quali certificate authority possono emettere certificati per quel dominio. Se ne hai uno — spesso ereditato da una configurazione precedente o aggiunto seguendo una raccomandazione di un security scan — e non include la CA utilizzata dalla tua piattaforma, l'emissione fallisce. L'unico posto in cui viene indicato è nei log della CA, ai quali non puoi accedere.

dig +short example.com CAA
dig +short app.example.com CAA

Un output vuoto significa che non ci sono restrizioni, ed è corretto. Se invece ricevi dei record, aggiungi la CA utilizzata dalla piattaforma oppure rimuovi la restrizione.

L'ordine più rapido per individuare il problema

1. Esegui dig sul record usando un resolver pubblico. Se non ricevi alcuna risposta, il record è errato oppure non si è ancora propagato: fermati qui.
2. Verifica se il record è sottoposto a proxy. In tal caso, disattiva il proxy oppure escludi il percorso ACME.
3. Controlla il CAA sia sull'apice sia sul subdomain.
4. Solo a questo punto valuta la possibilità che il problema sia della piattaforma.

Il novanta per cento delle convalide bloccate si risolve al passaggio 1 o al passaggio 2.

Come funziona su Dockup

Due scelte progettuali eliminano gran parte delle verifiche manuali.

Il record DNS viene creato automaticamente. Se la tua zona è su Cloudflare e hai collegato l'account, aggiungendo un dominio il record viene scritto automaticamente, senza dover copiare manualmente un valore:

dockup domain add app.example.com my-project/my-api --port 3000 --cloudflare

Questo elimina l'intera categoria di errori dovuti a refusi e tipi di record errati: la piattaforma sa se deve usare un CNAME o un record A e crea quello corretto.

L'autorizzazione richiede due permessi. Zone:Read e DNS:Edit, e nient'altro. Dockup non può leggere le altre zone, modificare le impostazioni dell'account o intervenire su elementi per i quali non ha ricevuto autorizzazione. Collegare l'automazione DNS non dovrebbe richiedere di consegnare un account.

Lo stato della verifica e quello del certificato sono visibili per ogni dominio, invece di essere raggruppati in un unico stato generale. In questo modo, "DNS verificato ma TLS in sospeso" descrive esattamente la situazione: due passaggi distinti, di cui uno è terminato.

Domande frequenti

Quanto dovrebbe richiedere l'emissione del certificato? Di solito meno di un minuto, una volta che il DNS risolve correttamente. Se è in sospeso da più di circa quindici minuti, probabilmente c'è qualcosa che lo blocca, non si tratta semplicemente di lentezza.

Perché il mio dominio funziona nel browser ma la convalida fallisce? Perché il browser segue i redirect e usa HTTPS, mentre la challenge non fa né l'una né l'altra cosa. Un proxy che serve perfettamente il tuo sito può comunque intercettare la richiesta ACME in HTTP non cifrato.

Posso usare un CNAME sul dominio root? Non nel DNS standard. Usa una funzionalità del provider come ALIAS o CNAME flattening oppure punta l'apice a un subdomain con un redirect.

Che cos'è un record CAA e mi serve? Limita le certificate authority autorizzate a emettere certificati per il tuo dominio. Non è obbligatorio, ma se ne hai uno che non include la CA della tua piattaforma, l'emissione fallisce senza messaggi espliciti.