Creare un certificato wildcard Let's Encrypt

Un certificato wildcard Let’s Encrypt è utile quando più sottodomini devono essere protetti con un unico certificato, ad esempio app.example.com, vpn.example.com e portal.example.com. Può essere una soluzione pratica per Sophos ZTNA, reverse proxy, ambienti di test o diversi servizi web interni.

È importante partire dalla giusta aspettativa: i certificati Let’s Encrypt hanno una durata breve. Il loro vantaggio non è una lunga validità, ma l’emissione gratuita e l’automazione. Se il certificato viene creato manualmente tramite un record DNS TXT, il rinnovo successivo deve essere pianificato consapevolmente.

Se il certificato deve essere creato direttamente su Sophos Firewall per WAF, WebAdmin o portali, in genere è preferibile il metodo integrato nel firewall: Configurare i certificati Let’s Encrypt su Sophos Firewall. Questo articolo descrive il metodo wildcard esterno con Certbot.

Quando conviene un certificato wildcard

Un certificato wildcard copre un livello sotto un dominio. *.example.com copre quindi portal.example.com, ma non copre automaticamente example.com né a.b.example.com.

• Molti sottodomini nella stessa zona: Un certificato wildcard può semplificare l’amministrazione.
• Un solo servizio pubblico: Un certificato per un FQDN specifico è spesso più chiaro.
• Il certificato verrà usato su più sistemi: Un certificato wildcard può essere pratico, ma la distribuzione della chiave privata deve essere strettamente controllata.
• È necessario un rinnovo completamente automatico: Occorre prevedere un provider DNS con plugin per Certbot o un altro client ACME.
• Sophos Firewall deve proteggere solo WAF, WebAdmin o portali: Conviene verificare il metodo Let’s Encrypt integrato nel firewall.

Un certificato wildcard non è intrinsecamente più sicuro. Se la stessa chiave privata è memorizzata su più sistemi, aumenta l’impatto di una sua compromissione. È quindi necessario documentare su quali sistemi è stato importato il certificato e chi è responsabile della chiave privata.

Requisiti

Per ottenere un certificato wildcard sono necessari:

• un dominio o una zona di sottodominio delegata sotto il proprio controllo
• accesso ai record DNS TXT del dominio
• un server Linux o una postazione di amministrazione con Certbot
• l’autorizzazione a eseguire Certbot con privilegi root
• un piano per rinnovo, importazione e conservazione della chiave
• accesso al sistema di destinazione, come Sophos Central ZTNA, un reverse proxy o un firewall

I certificati wildcard vengono convalidati tramite la challenge DNS-01. Viene creato un record TXT in _acme-challenge.example.com. Let’s Encrypt controlla questo record DNS e quindi emette il certificato. La documentazione Let’s Encrypt sui tipi di challenge illustra i metodi di convalida di base.

Installare Certbot

La pagina del progetto Certbot consiglia l’installazione tramite Snap per molti ambienti Linux. Su un sistema Linux adatto, la procedura di base è:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Se Certbot è già stato installato tramite apt, dnf o un altro gestore di pacchetti, occorre prima verificare quale eseguibile viene effettivamente utilizzato. Metodi di installazione paralleli possono altrimenti portare all’uso di una versione inattesa o a job di rinnovo diversi da quelli previsti.

Creare manualmente il certificato wildcard

Per una convalida DNS manuale, Certbot viene eseguito con --manual e --preferred-challenges dns. In questo esempio, il certificato deve coprire sia example.com sia *.example.com:

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'

Certbot mostra quindi uno o più valori TXT. Se example.com e *.example.com vengono richiesti insieme, si generano due challenge DNS-01 distinte. Entrambi i valori devono essere aggiunti come record TXT separati in _acme-challenge.example.com. Il secondo record va aggiunto senza sovrascrivere il primo.

Prima di proseguire in Certbot, almeno i name server autoritativi del dominio e un resolver esterno devono restituire i valori TXT attesi. Un singolo resolver è solo un’indicazione, perché i provider DNS possono distribuire le modifiche con velocità diverse a seconda della posizione.

Verifica pratica:

dig TXT _acme-challenge.example.com @1.1.1.1

I name server autoritativi si possono individuare con dig NS example.com. Lo stesso record TXT può quindi essere interrogato direttamente su uno di questi server. Dopo una convalida riuscita, i valori TXT della challenge non più necessari vengono rimossi. I valori obsoleti rendono meno chiare le verifiche successive e, se si accumulano, aumentano inutilmente le dimensioni della risposta DNS.

• certonly: Ottenere o rinnovare un certificato senza installarlo.
• --manual: Impostare manualmente il valore DNS.
• --preferred-challenges dns: Utilizzare la challenge DNS-01.
• -d example.com: Includere il dominio root.
• -d '*.example.com': Includere il dominio wildcard.

Il dominio root e il dominio wildcard sono nomi distinti. Se viene richiesto solo *.example.com, example.com non viene incluso automaticamente. Quando i due nomi vengono richiesti insieme, possono essere necessari più record TXT con lo stesso nome. DNS lo consente e la convalida spesso fallisce proprio perché un valore TXT esistente viene sovrascritto per errore.

Individuare i file del certificato

Certbot mostra il nome effettivo del certificato, i domini inclusi, la data di scadenza e i percorsi dei file con questo comando di sola lettura:

sudo certbot certificates

Dopo un’emissione riuscita, i file si trovano in genere in:

/etc/letsencrypt/live/example.com/

File importanti:

• fullchain.pem: Certificato con i certificati intermedi.
• cert.pem: Solo il certificato del server.
• privkey.pem: Chiave privata.
• chain.pem: Certificati intermedi.

Molti sistemi di destinazione richiedono fullchain.pem e privkey.pem. Alcune finestre di importazione prevedono certificato e chiave separati, mentre altre richiedono anche la catena. Prima dell’importazione bisogna verificare quale formato si aspetta il sistema di destinazione.

⚠️ privkey.pem è la chiave privata. Non deve essere inserita in ticket, chat, e-mail o archivi non protetti. Chiunque ottenga la chiave privata può usare impropriamente il certificato.

Pianificare il rinnovo

Il metodo manuale con --manual è semplice per test e operazioni una tantum, ma è solo parzialmente adatto ai certificati di produzione. Senza automazione, per ogni rinnovo deve essere impostato un nuovo valore DNS TXT.

Per l’uso in produzione esistono tre opzioni ragionevoli:

• Plugin DNS per il provider: Adatto quando Certbot può aggiornare i record DNS tramite API.
• Altro client ACME con automazione DNS: Adatto quando il provider o la piattaforma dispone di un supporto migliore con un altro client.
• Rinnovo manuale con un responsabile e un promemoria: Indicato solo per test o certificati utilizzati raramente.

Le credenziali dell’API DNS sono particolarmente sensibili. Un token DNS deve essere limitato alla zona necessaria e, se possibile, ai tipi di record richiesti. Le credenziali con ampi diritti di amministrazione del dominio non devono essere memorizzate senza protezione su un server web.

Il rinnovo viene normalmente testato con:

sudo certbot renew --dry-run

Per i certificati creati con convalida DNS manuale, questo test è significativo solo se il processo DNS è automatizzato o se gli hook manuali funzionano correttamente.

Un rinnovo riuscito sul sistema Certbot non aggiorna automaticamente un certificato già importato in Sophos Firewall, ZTNA o un reverse proxy. È necessaria una reimportazione documentata oppure un processo di distribuzione testato che venga eseguito solo dopo un rinnovo riuscito. Dopo ogni distribuzione si verificano nomi, catena e nuova data di scadenza direttamente sul sistema di destinazione.

Importare negli ambienti Sophos

Prima di importare il certificato in Sophos ZTNA, un firewall, un reverse proxy o un altro sistema collegato a Sophos, occorre verificare quanto segue:

• Il nome del certificato corrisponde all’hostname pubblico?
• Oltre al wildcard è necessario anche il dominio root?
• Il sistema di destinazione richiede fullchain.pem o componenti separati?
• Accetta la chiave privata o questa deve essere convertita in un altro formato?
• Esiste una procedura documentata per il prossimo rinnovo?
• È noto su quali sistemi è stato importato lo stesso certificato?

Se il certificato serve soltanto per WAF, WebAdmin o i portali su Sophos Firewall, il processo integrato è spesso più semplice, perché emissione e rinnovo avvengono direttamente sul firewall. Per veri certificati wildcard resta invece rilevante il metodo esterno con Certbot o ACME. Importare e assegnare certificati su Sophos Firewall spiega poi come controllare la chiave privata, la catena CA e l’assegnazione al servizio.

Errori tipici

• La convalida non riesce: Il record TXT non è ancora visibile, il nome della zona DNS è errato oppure uno dei valori TXT è stato sovrascritto. Verificare con dig TXT _acme-challenge.example.com @1.1.1.1.
• Il certificato non copre example.com: È stato richiesto solo *.example.com. Aggiungere il dominio root con -d example.com.
• Il certificato non copre a.b.example.com: Il wildcard copre un solo livello di sottodominio. Pianificare un certificato separato o un wildcard adatto alla zona più profonda.
• Il rinnovo non viene eseguito automaticamente: Il metodo DNS manuale non è automatizzato. Verificare la disponibilità di un plugin DNS adatto o di un altro client ACME.
• Certbot rinnova il certificato, ma il sistema di destinazione presenta ancora quello precedente: La reimportazione o il processo di distribuzione non è stato eseguito. Controllare il numero di serie o la data di scadenza direttamente sulla destinazione.
• L’importazione non riesce: Il file o il formato non è corretto. Confrontare i requisiti relativi a fullchain.pem, cert.pem, privkey.pem e alla catena di certificati.
• Le copie della chiave creano un rischio di sicurezza: La chiave privata è memorizzata su più sistemi. Documentare posizione, autorizzazioni di accesso e punti di importazione.

Lista di controllo

• Dominio e livello di sottodominio necessario definiti.
• Dominio root e wildcard selezionati consapevolmente.
• Accesso DNS e autorizzazione a creare record TXT disponibili.
• Certbot installato in modo coerente.
• Challenge DNS-01 convalidata correttamente.
• File del certificato e chiave privata archiviati in sicurezza.
• Sistema di destinazione e formato di importazione necessario noti.
• Rinnovo pianificato con un responsabile, un promemoria o l’automazione DNS.
• Reimportazione o processo di distribuzione al sistema di destinazione testato.
• Vecchi certificati e chiavi rimossi in modo controllato dopo una migrazione riuscita.

Domande frequenti