Configurare un dominio personalizzato con HTTPS richiede un record TXT, un record CNAME e una breve attesa. Aggiungi l'hostname in Elido, copi due valori DNS che ti fornisce, e il certificato TLS viene emesso automaticamente la prima volta che qualcuno apre un link su quel dominio. La parte lenta è la propagazione del DNS, che controlli con il TTL. Questo articolo percorre i cinque passaggi, poi spiega il meccanismo così sai dove guardare quando un passaggio si blocca.
Tutto quanto segue è stato verificato sul codice e sulla dashboard attuali di Elido il 2026-10-09. Dove una funzione correlata non è ancora costruita, l'articolo lo dice.
Perché il TLS conta su un link breve
Un link breve è un redirect, e la risposta del redirect è l'intero contenuto. Un 301 o 302 con un header Location porta il tuo URL di destinazione. Se la prima richiesta viaggia su HTTP in chiaro, chiunque si trovi sul percorso di rete può leggere quella destinazione prima che il browser la segua.
I codici QR peggiorano la situazione. Chi scansiona un codice in una vetrina o su un manifesto non ha alcun rapporto precedente con l'URL, quindi la barra degli indirizzi è l'unico segnale di fiducia che riceve. Un avviso del browser alla scansione è la peggiore prima impressione possibile, e la tiratura di stampa l'hai già pagata.
Sui domini brevi condivisi di Elido il certificato appartiene a Elido, quindi il lucchetto è reale ma il nome che porta non è il tuo. Su go.acme.com il nome è tuo. Per le basi di DNS e TLS dietro tutto questo, vedi l'articolo cornerstone sui link brevi con dominio personalizzato.
Passaggio 1: scegli l'hostname
Scegli un sottodominio breve che controlli e che non usi per altro: go.example.com, links.example.com o simili. Il prefisso compare in ogni link che invii, quindi più è corto meglio è.
Usa un sottodominio, non la root nuda. La RFC 1034 sezione 3.6.2 dice che un nome con un CNAME non può contenere altri dati, e la root di una zona contiene sempre record SOA e NS, quindi lì un CNAME non è consentito. Alcuni provider DNS lo simulano con record ALIAS o flattened, ma questi rispondono con indirizzi IP anziché con un CNAME. La verifica di Elido chiede il CNAME vero e proprio, quindi una root flattened non passerà.
Altre due regole valgono quando registri il nome. L'hostname deve essere un nome di dominio pienamente qualificato in minuscolo, e i nomi sotto elido.me o elido.app sono riservati.
Passaggio 2: aggiungi il dominio in Elido
Apri Domains nella barra laterale della dashboard, scrivi l'hostname e clicca Add domain. Spunta la casella wildcard solo se vuoi che funzioni ogni sottodominio di quel nome, come in *.go.example.com. Di solito non serve. Elido mostra poi i due record DNS, ognuno con un pulsante per copiarlo.
Lo stesso passaggio tramite API, per script di onboarding o workspace dei clienti:
curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/domains \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"hostname": "go.example.com", "is_wildcard": false}'
La chiamata richiede un ruolo che possa gestire i domini. Un nuovo dominio torna con stato pending, un verify_token e un oggetto instructions che contiene i valori esatti dei record:
{
"domain": {
"id": 42,
"hostname": "go.example.com",
"status": "pending",
"is_wildcard": false
},
"instructions": {
"txt_record": "_elido-verify.go.example.com TXT \"verify=<token>\"",
"cname_record": "go.example.com CNAME edge.elido.me"
}
}
I domini personalizzati richiedono un piano a pagamento. Se provi a registrarne uno su un workspace Free, oltre il numero di domini del tuo piano o con un abbonamento in pausa o annullato, l'API risponde 402, il codice che gestirei per primo in qualsiasi script di onboarding, perché è quello in cui un cliente si imbatte il primo giorno. Un hostname duplicato riceve 409. Le agenzie che gestiscono molti domini dei clienti dovrebbero leggere la pagina soluzioni per le agenzie per il modello dei workspace.
Passaggio 3: pubblica i due record DNS
Aggiungi entrambi i record presso il tuo provider DNS, esattamente come mostrati:
go.example.com CNAME edge.elido.me.
_elido-verify.go.example.com TXT "verify=<your-token>"
Il CNAME instrada il traffico verso Elido. Il record TXT dimostra che possiedi la zona. Servono entrambi, e il valore del TXT deve corrispondere esattamente al token.
Per una registrazione wildcard il CNAME diventa *.go.example.com, mentre il record TXT resta in _elido-verify.go.example.com, sul nome padre senza asterisco.
Imposta un TTL di 300 secondi su entrambi i record se il tuo provider lo permette. Molte zone hanno come predefinito 3600 secondi, e un TTL lungo è ciò che trasforma un lavoro da cinque minuti in uno da un'ora.
Una nota sui provider conta più delle altre. Se usi Cloudflare, lascia il CNAME come solo DNS. La documentazione di Cloudflare dice che un record in proxy riceve risposta con gli indirizzi IP di Cloudflare anziché con il contenuto del record (consultata il 2026-10-09). Un nome in proxy quindi non restituisce mai il CNAME che Elido cerca, e la verifica non passerà.
Passaggio 4: attendi la verifica
Non devi cliccare nulla. Un worker in background dentro l'API di Elido controlla ogni dominio in sospeso a intervalli, 30 secondi per impostazione predefinita, usando il resolver pubblico di Google a 8.8.8.8. Approva il dominio solo quando valgono entrambe le condizioni:
- Il record TXT in
_elido-verify.<hostname>contiene esattamenteverify=<token>. - L'hostname ha un CNAME che si risolve nel target edge di Elido.
Quando entrambe passano, lo stato cambia in verified. Interrogalo tu stesso se stai scrivendo uno script per la configurazione:
curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
-H "Authorization: Bearer $ELIDO_API_TOKEN"
Per saltare l'attesa del prossimo ciclo, invia POST .../domains/42/verify. Restituisce 202 e porta il dominio in testa alla coda. Un dominio che resta pending per 24 ore viene contrassegnato failed con il motivo "verification timeout", e la stessa chiamata verify riporta un dominio failed a pending così puoi riprovare dopo aver corretto il DNS.
Se si blocca, interroga i record nello stesso modo in cui lo fa il controllo:
dig @8.8.8.8 TXT _elido-verify.go.example.com +short
dig @8.8.8.8 CNAME go.example.com +short
Il primo dovrebbe stampare "verify=<your-token>". Il secondo dovrebbe stampare edge.elido.me., punto finale incluso.
Passaggio 5: la prima richiesta emette il certificato
Quando lo stato è verified, non ti resta più nulla da fare. Elido non pre-emette i certificati. Il livello TLS ne emette uno on demand, la prima volta che un browser apre una connessione TLS per il tuo hostname.
Prima di chiedere qualsiasi cosa a Let's Encrypt, l'edge chiama un controllo di autorizzazione sull'API di Elido. La risposta è sì solo se l'hostname è nello stato verified o active, oppure se ricade sotto una registrazione wildcard verificata. Qualunque altra risposta, incluso un nome sconosciuto, rifiuta l'handshake e nessun certificato viene richiesto. È quel controllo a impedire a un estraneo di puntare un milione di hostname verso Elido e bruciare i rate limit dell'autorità di certificazione.
Quando il controllo passa, l'emissione usa la challenge HTTP-01 della RFC 8555: l'autorità di certificazione chiede un token in /.well-known/acme-challenge/ sul tuo hostname su HTTP in chiaro, l'edge risponde, e il certificato viene emesso e messo in cache. Il primo visitatore attende un momento per questo. Le richieste successive riusano il certificato in cache.
Un'abitudine pratica: apri tu stesso https://go.example.com subito dopo la verifica, così il certificato esiste prima che il primo a richiederlo sia un cliente o una scansione di un codice QR.
Passa l'id del dominio come domain_id quando crei un link. Il link è attivo su https://go.example.com/<slug> subito. La pagina Domains mostra anche i clic degli ultimi 30 giorni per hostname. Il riferimento completo, comprese le indicazioni sul CAA, è nella guida ai domini personalizzati, e la panoramica del prodotto è nella pagina della funzione domini personalizzati.
Cosa significano i valori di stato
| Stato | Significato | Cosa fare |
|---|---|---|
pending | Dominio registrato, DNS non ancora visto | Controlla TXT e CNAME con dig |
verified | Entrambi i record trovati, i certificati possono essere emessi | Apri una volta l'URL HTTPS, poi crea i link |
failed | Non verificato entro 24 ore, il motivo è sulla riga | Correggi il DNS, poi richiama l'endpoint verify |
active | Accettato dal gate come verified | Niente; trattalo come verified |
Nella build attuale un dominio sano resta a verified. Il valore active esiste nel modello dei dati e nel filtro della dashboard, e il gate dei certificati accetta entrambi, ma per ora nulla porta un dominio a quello stato.
Insidie comuni
Record CAA che escludono Let's Encrypt. Un record CAA limita quali autorità possono emettere per un nome, ed è ereditato dai sottodomini (consultato il 2026-10-09). Se la tua zona ha example.com CAA 0 issue "digicert.com", l'emissione per go.example.com viene rifiutata. Aggiungi go.example.com CAA 0 issue "letsencrypt.org" o amplia il record all'apex.
Un proxy o una CDN davanti al CNAME. La nuvola arancione di Cloudflare è il caso più comune, trattato nel passaggio 3. Qualsiasi livello che risponde al DNS o all'HTTP al posto tuo rompe sia il controllo del CNAME sia la challenge HTTP-01.
Wildcard non significa certificati wildcard. Secondo la documentazione sulle challenge di Let's Encrypt, HTTP-01 non può emettere certificati wildcard, e DNS-01 richiede accesso in scrittura alla tua zona (consultata il 2026-10-09). Quindi una registrazione wildcard copre il routing di ogni sottodominio, ma client1.go.example.com e client2.go.example.com ottengono ciascuno il proprio certificato al primo utilizzo. Let's Encrypt limita i nuovi certificati per dominio registrato a 50 ogni 7 giorni (consultato il 2026-10-09), quindi l'onboarding di centinaia di sottodomini nuovi in una settimana va pianificato.
Rimuovere il CNAME in seguito. Oggi il controllo DNS gira solo mentre un dominio è pending. Una volta verificato un dominio, Elido non lo ricontrolla, quindi un CNAME cancellato si manifesta come redirect che falliscono e rinnovi del certificato che falliscono, non come un cambio di stato o una notifica. Monitora il record dal tuo lato. Un controllo di salute periodico con uno stato degradato e un periodo di tolleranza è pianificato, non costruito.
Marius Voß è DevRel + edge infra in Elido. Si occupa del percorso dei redirect e del flusso dei domini personalizzati.
Altri articoli del blog
Domande frequenti
Quanto tempo richiede la configurazione del TLS su un dominio personalizzato?
Aggiungere il dominio richiede un minuto, pubblicare i due record DNS qualche minuto in più, poi si attende la propagazione del DNS. Elido controlla i domini in sospeso ogni 30 secondi per impostazione predefinita, quindi la verifica arriva poco dopo che i tuoi record diventano visibili. Con un TTL di 300 secondi di solito bastano minuti; con un TTL di 3600 secondi può volerci di più. Il certificato viene emesso alla prima richiesta HTTPS verso l'hostname verificato, non prima.
Quali record DNS servono a Elido per un dominio personalizzato?
Due. Un record TXT in _elido-verify.<il tuo hostname> con il valore verify=<token> dimostra che controlli la zona, e un CNAME dal tuo hostname al target edge di Elido instrada il traffico. Elido mostra i due valori esatti nel momento in cui aggiungi il dominio, nella dashboard e nella risposta API, ed entrambi devono essere presenti perché il dominio venga verificato.
Posso usare un dominio root come example.com per i link brevi?
Non in modo affidabile. Lo standard DNS non permette un CNAME all'apex della zona, e la verifica di Elido cerca una vera risposta CNAME, quindi un record flattened o ALIAS che restituisce solo indirizzi IP non passerà. Usa un sottodominio come go.example.com o links.example.com. È anche più breve da digitare in ogni link che condividi.
Elido emette un certificato wildcard per il mio dominio?
No. La registrazione di un dominio wildcard permette di servire ogni sottodominio sotto il tuo nome, ma ogni hostname ottiene il proprio certificato alla sua prima richiesta tramite la challenge HTTP-01. Let's Encrypt emette certificati wildcard solo tramite la challenge DNS-01, che richiede accesso in scrittura alla tua zona DNS, e Elido non ha quell'accesso. Per i visitatori il risultato è lo stesso.
Perché il mio dominio resta in stato pending?
O il valore del TXT non corrisponde esattamente al token, o il CNAME non si risolve nel target edge di Elido, oppure un proxy risponde al posto del tuo CNAME. Elido cerca entrambi i record tramite un resolver pubblico, quindi controllali con dig da fuori della tua rete. Un dominio ancora in sospeso dopo 24 ore viene contrassegnato come failed con un motivo, e dopo puoi richiedere una nuova verifica.
I domini personalizzati funzionano su tutti i piani Elido?
No. I workspace Free non hanno alcuna quota di domini personalizzati. I piani a pagamento Pro e Business includono domini personalizzati, e il numero che puoi collegare dipende dalla dimensione del piano, quindi controlla la pagina dei prezzi per il tuo livello. Aggiungere un dominio oltre il limite, o su un abbonamento in pausa o annullato, viene rifiutato con un errore payment-required.
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Senza registrazione. Crea un account gratuito per 50 link al mese.