Certificati HTTPS per servizi locali: rinnovo automatico con Let's Encrypt

L’automazione dei certificati TLS non riguarda più soltanto i siti pubblici. Anche CRM, wiki, pannelli amministrativi e applicazioni accessibili esclusivamente dalla rete aziendale devono usare HTTPS senza mostrare avvisi su notebook, smartphone e dispositivi personali. Continuare ad acquistare un certificato annuale e copiarlo manualmente su ogni server, però, non rappresenta più una soluzione sostenibile: basta dimenticare una scadenza per rendere improvvisamente inaccessibili servizi essenziali.

Il problema descritto nasce da tre vincoli frequenti: i server interni usati in uffici e aziende non possono ricevere connessioni da Internet, il DNS autoritativo non offre API e un’autorità di certificazione interna richiederebbe l’installazione di una nuova radice di fiducia su tutti i dispositivi.

Una soluzione moderna ed efficace consente di mantenere invariata la configurazione DNS principale e affidare a un servizio separato solo i record richiesti dal protocollo ACME (Automatic Certificate Management Environment) per verificare che chi richiede il certificato controlli effettivamente il nome di dominio.

Perché HTTP-01 non è adatto ai servizi interni

Per ottenere un certificato da una Certification Authority (CA) pubblica, il client ACME deve dimostrare di controllare il nome richiesto. Con la verifica HTTP-01, l’autorità prova a recuperare un file temporaneo attraverso una URL simile alla seguente:

http://crm.example.com/.well-known/acme-challenge/token

Il nome deve quindi risolvere verso un sistema raggiungibile pubblicamente sulla porta 80. Si può predisporre un reverse proxy o un server collocato in DMZ che esponga soltanto il percorso ACME, ma molte aziende preferiscono non aprire alcuna connessione in ingresso, nemmeno verso un componente separato.

La verifica DNS-01 evita completamente il problema: l’autorità non contatta il server applicativo, ma cerca un record TXT nel DNS pubblico. Esempio:

_acme-challenge.crm.example.com

L’applicativo locale può continuare a usare un indirizzo privato, essere risolto soltanto dal DNS aziendale e restare irraggiungibile da Internet. L’unico elemento pubblico necessario è il record DNS che dimostra temporaneamente il controllo del dominio.

DNS-01 consente inoltre di richiedere certificati wildcard, per esempio per:

*.internal.example.com

Un singolo certificato può così proteggere numerosi servizi, purché la sua distribuzione e la relativa chiave privata siano gestite con attenzione.

Il vero ostacolo: aggiornare automaticamente il record TXT

Il normale flusso DNS-01 prevede che il client ACME:

1. riceva dalla CA il valore da pubblicare;
2. crei il record TXT tramite le API del provider DNS;
3. attenda la propagazione;
4. chieda alla CA di eseguire la verifica;
5. elimini il record dopo l’emissione.

Senza API, l’amministratore dovrebbe modificare il record TXT manualmente a ogni rinnovo: con Let’s Encrypt, il certificato sarebbe gratuito, ma l’operazione resterebbe sostanzialmente manuale.

Delegare _acme-challenge con un CNAME

Una soluzione consolidata consiste nel creare una sola volta un record CNAME che rimanda a un dominio gestito da un servizio dotato di API. Supponiamo che l’applicazione interna risponda al nome:

crm.example.com

Nel DNS principale si può inserire manualmente:

_acme-challenge.crm.example.com. CNAME crm.example.acme-validation.net.

Il dominio acme-validation.net può risiedere presso Cloudflare o un altro provider che consenta gli aggiornamenti automatici. Il client ACME non modifica più la zona example.com: scrive il valore TXT nella destinazione del CNAME.

Let’s Encrypt documenta la possibilità di delegare DNS-01 tramite CNAME o mediante record NS; raccomanda però di affidare la zona delegata a infrastrutture adeguatamente protette.

Client come acme.sh supportano esplicitamente il cosiddetto DNS alias mode, pensato proprio per aggiornare una zona diversa da quella del nome incluso nel certificato. Lo stesso progetto permette di automatizzare emissione, rinnovo e installazione dei file senza richiedere necessariamente privilegi di root.

CNAME per ogni host o certificato wildcard?

La delega deve essere progettata con attenzione: per un certificato relativo a crm.example.com, la CA cerca:

_acme-challenge.crm.example.com

Per wiki.example.com, invece, cerca:

_acme-challenge.wiki.example.com

Un singolo CNAME collocato su _acme-challenge.example.com non copre automaticamente tutti i sottodomini arbitrari. In molti casi occorre creare una delega per ciascun nome oppure organizzare i servizi sotto un sottodominio dedicato e usare un certificato wildcard.

Reverse proxy e rinnovo centralizzato

Caddy, Nginx, Traefik, HAProxy e altri reverse proxy possono concentrare l’accesso ai servizi interni:

https://crm.intra.example.com --> 10.10.20.15:8080
https://wiki.intra.example.com --> 10.10.20.16:3000
https://tickets.intra.example.com --> 10.10.20.17:8080

I client vedono un certificato pubblico valido, mentre le applicazioni continuano a funzionare sulle rispettive porte private. Caddy e Traefik includono funzioni ACME avanzate; Nginx e HAProxy possono invece ricevere i certificati da Certbot, acme.sh, lego o da un sistema centrale.

Il reverse proxy non risolve da solo il problema della verifica DNS; semplifica però distribuzione, sostituzione e caricamento dei certificati.

DNS-PERSIST-01 promette di eliminare gli aggiornamenti continui

DNS-PERSIST-01 nasce per superare uno dei limiti principali di DNS-01. Invece di pubblicare un TXT diverso a ogni rinnovo, il proprietario configura una credenziale persistente nel DNS. Il client dimostra poi di possedere la chiave privata associata, senza dover modificare continuamente la zona.

La proposta risulta particolarmente interessante quando:

• il provider DNS non offre API;
• i record possono essere inseriti manualmente una sola volta;
• non è possibile esporre la porta 80;
• serve mantenere il certificato pubblicamente attendibile.

Let’s Encrypt aveva inizialmente pianificato il supporto in staging per il primo trimestre del 2026 e il debutto ufficiale nel secondo trimestre. Il progetto ha però incontrato ritardi legati all’evoluzione della specifica; a luglio 2026 il relativo thread di riferimento risultava ancora attivo e non è ancora prudente considerare DNS-PERSIST-01 una funzione universalmente disponibile in produzione e supportata dai principali client.

Può diventare la soluzione ideale per installazioni bloccate su DNS senza API, ma oggi un’infrastruttura aziendale non dovrebbe basare il proprio piano di rinnovo esclusivamente sulla sua futura disponibilità.

I certificati dureranno sempre meno

L’automazione non è più soltanto una comodità. Il CA/Browser Forum ha approvato una riduzione progressiva della validità massima dei certificati TLS pubblici:

• 200 giorni dal 15 marzo 2026;
• 100 giorni dal 15 marzo 2027;
• 47 giorni dal 15 marzo 2029.

La transizione riduce anche il periodo durante il quale le autorità possono riutilizzare alcune informazioni di validazione: il modello del certificato acquistato una volta all’anno e installato manualmente è quindi destinato a scomparire.

Con una validità massima di 47 giorni, un’organizzazione dovrà rinnovare molto prima della scadenza, probabilmente ogni quattro settimane circa. Copiare manualmente chiavi e certificati su più server diventerebbe troppo rischioso anche per una realtà di piccole dimensioni.

Let’s Encrypt supporta anche gli indirizzi IP, ma non quelli privati

Let’s Encrypt consente oggi di ottenere certificati associati direttamente a un indirizzo IP, senza dover necessariamente usare un nome di dominio.

La novità riguarda però soltanto gli indirizzi IP pubblici e univocamente assegnati, per i quali il richiedente può dimostrare il controllo tramite ACME. Non è invece possibile emettere un certificato pubblicamente attendibile per gli indirizzi locali: gli stessi IP sono riutilizzati in milioni di reti private e nessuna organizzazione può rivendicarne il possesso esclusivo.

C’è però un limite importante: per ottenere e rinnovare il certificato IP, Let’s Encrypt deve verificare il controllo dell’indirizzo tramite HTTP-01 sulla porta 80 oppure TLS-ALPN-01 sulla porta 443; DNS-01 non è utilizzabile per gli indirizzi IP. Di conseguenza, almeno il componente incaricato della validazione deve poter rispondere alle connessioni provenienti da Internet su quell’indirizzo pubblico.

La strada, quindi, è tecnicamente possibile ma non coincide con il requisito comune di mantenere ogni componente completamente irraggiungibile dall’esterno. Inoltre presenta altri inconvenienti: il certificato deve essere rinnovato ogni pochi giorni (i certificati appartengono al profilo shortlived e durano 160 ore, poco più di 6 giorni: devono quindi essere rinnovati continuamente tramite un client compatibile), l’IP pubblico deve essere statico o sufficientemente stabile e il router deve supportare correttamente il NAT loopback.

Per un servizio esclusivamente locale, il nome DNS continua generalmente a offrire una configurazione più “pulita”.