Crea il certificato Let's Encrypt con caratteri jolly

Un Let’s Encrypt Wildcard Certificate è utile se è necessario proteggere più sottodomini con un certificato comune, ad esempio app.example.com, vpn.example.com e portal.example.com. Ciò può essere utile per Sophos ZTNA, proxy inversi, ambienti di test o più servizi web interni.

Ciò che è importante è l’aspettativa: i certificati Let’s Encrypt sono di breve durata. Il vantaggio non sta nel lungo termine, ma nella libera emissione e nell’automazione. Se il certificato viene creato manualmente utilizzando una voce DNS TXT, il successivo rinnovo deve essere pianificato consapevolmente.

Se il certificato deve essere creato direttamente su un Sophos Firewall per WAF, WebAdmin o portali, il metodo firewall integrato è solitamente migliore: Configurazione di Sophos Firewall Let’s Encrypt dei certificati. Questo articolo descrive il percorso con caratteri jolly esterni con Certbot.

Quando un certificato con caratteri jolly ha senso

Un certificato con caratteri jolly copre un livello inferiore a un dominio. Quindi *.example.com si adatta a portal.example.com, ma non automaticamente per example.com stesso e nemmeno per a.b.example.com.

• Molti sottodomini nella stessa zona: Il certificato con caratteri jolly può semplificare l’amministrazione.
• Un solo servizio pubblico: il certificato FQDN singolo è spesso più pulito.
• Il certificato deve essere utilizzato su più sistemi: Il certificato con caratteri jolly può essere pratico, ma controlla rigorosamente la distribuzione delle chiavi.
• È richiesto il rinnovo completamente automatico: Pianifica il provider DNS con il plug-in Certbot o un altro client ACME.
• Sophos Firewall è destinato esclusivamente alla protezione di WAF/WebAdmin/Portals: Firewall integrato Controlliamo la crittografia.

Un certificato con caratteri jolly non rappresenta di per sé un vantaggio in termini di sicurezza. Infatti, se la stessa chiave privata si trova su più sistemi, l’impatto della perdita della chiave aumenta. Pertanto, dovrebbe essere documentato dove è stato importato il certificato e chi gestisce la chiave privata.

Requisiti

Per un certificato jolly è necessario:

• il tuo dominio o zona sottodominio
• Accesso ai record DNS TXT del dominio
• un server Linux o un computer amministratore con Certbot
• Autorizzazione a eseguire Certbot con privilegi di root
• un piano di rinnovo, importazione e custodia delle chiavi
• Accesso al sistema di destinazione, ad esempio Sophos Central ZTNA, proxy inverso o firewall

I certificati con caratteri jolly vengono convalidati tramite la DNS-01 Challenge. Un record TXT è impostato in _acme-challenge.example.com. Let’s Encrypt controlla questa voce DNS e quindi emette il certificato. Let’s Encrypt descrive i tipi di sfida di base nella Documentazione sui tipi di sfida.

Installa Certbot

La Pagina del progetto Certbot consiglia l’installazione tramite Snap per molti ambienti Linux. Su un sistema Linux adatto, il processo di base è simile al seguente:

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 pacchetto, è necessario verificare in anticipo quale Certbot viene effettivamente utilizzato. In caso contrario, più percorsi di installazione paralleli porterebbero rapidamente a versioni errate o processi di rinnovo imprevisti.

Crea manualmente il certificato con caratteri jolly

Per la convalida DNS manuale, Certbot può essere avviato con --manual e --preferred-challenges dns. Nell’esempio, il certificato dovrebbe applicarsi sia a example.com che a *.example.com:

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

Certbot visualizza quindi uno o più valori TXT. Se example.com e *.example.com vengono richiesti contemporaneamente, Certbot crea due sfide DNS-01 separate. Entrambi i valori TXT devono essere aggiunti come record TXT separati sotto _acme-challenge.example.com. Il secondo record va quindi aggiunto in più, senza sostituire il primo.

Solo quando tutte le voci DNS sono visibili in tutto il mondo si dovrebbe confermare in Certbot e continuare la convalida.

Verifica pratica:

dig TXT _acme-challenge.example.com @1.1.1.1

• certamente: Richiedi o rinnova un certificato senza installarlo.
• --manual: Il valore DNS è impostato manualmente.
• --preferred-challenges dns: Utilizza la sfida DNS-01.
• -d example.com: Aggiungi ulteriore dominio root.
• -d '*.example.com': Includi dominio con caratteri jolly.

Il dominio principale e il dominio con caratteri jolly sono nomi separati. Se viene richiesto solo *.example.com, example.com stesso non viene incluso automaticamente. Se entrambi i nomi vengono richiesti contemporaneamente, possono essere necessari più record TXT con lo stesso nome. Questo è consentito in DNS ed è proprio il punto in cui le convalide spesso falliscono, perché un valore TXT esistente viene sostituito per errore.

Trova i file del certificato

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

/etc/letsencrypt/live/example.com/

File importanti:

• fullchain.pem: Certificato comprensivo di 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 maschere di importazione richiedono il certificato e la chiave separatamente, altre richiedono anche la catena. Prima dell’importazione dovrebbe essere chiaro quale formato si aspetta il sistema di destinazione.

⚠️ privkey.pem è la chiave privata. Questo file non deve finire in ticket, chat, email o archivi non sicuri. Chiunque abbia la chiave privata può abusare del certificato.

Rinnovo del piano

Il metodo manuale --manual è semplice per test e azioni individuali, ma è solo parzialmente adatto per certificati produttivi. Senza automazione, è necessario impostare un nuovo record DNS TXT ogni volta che viene rinnovato.

Esistono tre varianti pulite per un uso produttivo:

• Plugin DNS per il provider DNS: se Certbot è autorizzato a impostare record DNS tramite API.
• un altro client ACME con automazione DNS: se il fornitore o la piattaforma sono meglio supportati.
• rinnovo manuale con calendario e proprietario: solo per prove o certificati utilizzati raramente.

Quando viene utilizzato l’accesso API DNS, le credenziali API sono particolarmente critiche. A un token DNS dovrebbe essere consentito modificare solo la zona necessaria e, se possibile, solo i tipi di record necessari. L’accesso amministrativo a un dominio ampio non appartiene a un server Web non protetto.

Un test di rinnovo viene solitamente controllato con Certbot in questo modo:

sudo certbot renew --dry-run

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

Importa negli ambienti Sophos

Se il certificato viene utilizzato per Sophos ZTNA, un firewall, un proxy inverso o un altro sistema correlato a Sophos, è necessario verificare questi punti prima dell’importazione:

• Il nome del certificato corrisponde al nome host pubblico?
• È richiesto il dominio root oltre al carattere jolly?
• Il sistema di destinazione prevede fullchain.pem o componenti di certificato separati?
• La chiave privata è accettata o deve essere convertita in un altro formato?
• Esiste un processo documentato per il prossimo rinnovo?
• È chiaro su quali sistemi è stato importato lo stesso certificato?

Quando si tratta solo di WAF, WebAdmin o portali su Sophos Firewall, il processo del firewall integrato è spesso più semplice perché la creazione e il rinnovo avvengono direttamente sul firewall. Tuttavia, il percorso Certbot o ACME esterno rimane rilevante per i certificati con caratteri jolly reali.

Errori tipici

• La convalida non riesce: Record TXT non ancora visibile, nome zona DNS errato o uno dei valori TXT è stato sovrascritto. dig TXT _acme-challenge.example.com @1.1.1.1 controlla.
• Il certificato non si applica a example.com: solo *.example.com ha richiesto. Aggiungi inoltre il dominio root con -d example.com.
• Il certificato non si applica a a.b.example.com: Il carattere jolly copre solo un livello di sottodominio. pianifica il tuo certificato o il jolly adatto per una zona più profonda.
• Il rinnovo non funziona automaticamente: modo DNS manuale senza automazione. Controlla il plugin DNS o un altro client ACME.
• L’importazione non riesce: file o formato errato. fullchain.pem, cert.pem, privkey.pem e confronta le richieste a catena.
• Rischio per la sicurezza dovuto alle copie delle chiavi: la chiave privata è su più sistemi. Archiviazione dei documenti, accesso e posizioni di importazione.

Lista di controllo

• Impostazione del livello di dominio e sottodominio.
• Dominio root e carattere jolly selezionati deliberatamente.
• Accesso DNS e autorizzazione record TXT disponibili.
• Certbot installato in modo pulito.
• DNS-01 Challenge controllato con successo.
• File di certificato e chiave privata archiviati in modo sicuro.
• Sistema di destinazione e formato di importazione richiesto noti.
• Rinnovo programmato con automazione Proprietario, Calendario o DNS.
• I vecchi certificati e le chiavi vengono rimossi in modo controllato dopo la conversione riuscita.

Domande frequenti