NGINX introduce il supporto nativo per il protocollo ACME

Il team di sviluppo di NGINX ha annunciato la disponibilità della versione di anteprima del supporto ACME in NGINX. Questa novità introduce il nuovo modulo ngx_http_acme_module, progettato per offrire direttive integrate che consentono di richiedere, installare e rinnovare certificati direttamente all’interno della configurazione di NGINX, senza la necessità di ricorrere a procedure esterne. Il supporto ACME si basa sull’SDK NGINX-Rust ed è distribuito come modulo dinamico scritto in Rust, reso disponibile sia agli utenti di NGINX Open Source sia ai clienti enterprise di NGINX Plus attraverso la piattaforma NGINX One.

L’integrazione nativa del protocollo ACME in NGINX rappresenta un passo significativo nella semplificazione della gestione dei certificati SSL/TLS. La possibilità di configurare direttamente il processo di emissione e rinnovo tramite le direttive di NGINX riduce in modo sostanziale il rischio di errori manuali, migliorando al tempo stesso l’efficienza operativa. Questo approccio elimina gran parte della complessità e del sovraccarico tipicamente associati alla gestione dei certificati digitali, e riduce la dipendenza da strumenti esterni come Certbot. Ne risulta un flusso di lavoro più sicuro, lineare e centralizzato, con una superficie di attacco inferiore e una gestione più trasparente.

Un ulteriore vantaggio rispetto agli strumenti esterni è rappresentato dall’assenza di vincoli legati alla piattaforma. L’implementazione nativa in NGINX garantisce infatti una portabilità superiore e un’indipendenza che la rendono adatta a un’ampia gamma di contesti, dalle infrastrutture web aziendali consolidate agli ambienti cloud in rapida evoluzione. In questo modo, il nuovo modulo si configura come una soluzione versatile e affidabile, capace di rispondere alle esigenze di scalabilità, sicurezza e automazione che caratterizzano le moderne architetture applicative.

Che cos’è ACME ?

Il protocollo ACME (Automated Certificate Management Environment) è un sistema di comunicazione progettato per automatizzare le operazioni legate ai certificati digitali di sicurezza, in particolare SSL/TLS. Attraverso ACME è possibile gestire l’intero ciclo di vita di un certificato: dall’emissione iniziale alla convalida, dal rinnovo fino all’eventuale revoca. In questo modo, i client possono interagire con un’Autorità di Certificazione (CA) senza la necessità di interventi manuali, riducendo tempi, costi e complessità. La disponibilità di un protocollo standardizzato ha reso molto più semplice l’adozione di HTTPS come requisito di base per siti web, applicazioni e servizi online che necessitano di comunicazioni cifrate e sicure.

Lo sviluppo del protocollo ACME è stato avviato dall’Internet Security Research Group (ISRG) nell’ambito del progetto Let’s Encrypt, lanciato a fine 2015. L’iniziativa ha avuto un impatto rivoluzionario: per la prima volta sono stati offerti certificati SSL/TLS gratuiti e facilmente ottenibili, in un’epoca in cui l’acquisizione di certificati era spesso un processo manuale, costoso e soggetto a errori di configurazione. L’automazione introdotta da ACME ha cambiato radicalmente il paradigma, trasformando l’adozione del protocollo HTTPS da opzione avanzata a standard di fatto per il web moderno.

Con il tempo, il protocollo è stato ulteriormente migliorato con la specifica ACMEv2, che ha introdotto nuove funzionalità e ampliato gli scenari di utilizzo. Tra i principali aggiornamenti si trovano il supporto a nuove tipologie di challenge per la verifica dell’identità, metodi di autenticazione più flessibili, l’introduzione dei certificati wildcard (utili per proteggere interi domini e sottodomini con un unico certificato) e una maggiore robustezza generale della sicurezza. Grazie a queste evoluzioni, ACME è oggi considerato un pilastro dell’automazione nella gestione dei certificati digitali e uno strumento essenziale per garantire la diffusione di connessioni cifrate e sicure su scala globale.

Come funziona il protocollo ACME ?

Ci sono in realtà due spiegazioni per questa domanda. Una di alto livello che copre solo le basi e una più approfondita che copre l’aspetto tecnico. Cercheremo di mantenere un livello alto.

Una volta installato e configurato correttamente l’agente ACME, la procedura è in realtà piuttosto semplice. Parleremo della configurazione tra poco, ma per ora tenete presente che durante il processo di verifica che avviene al momento dell’installazione dell’agente verrà generata una coppia di chiavi che verrà utilizzata dall’agente e dalla CA. Queste chiavi sono talvolta denominate “chiavi di autorizzazione”.

Emissione/Rinnovo

Per ottenere un certificato digitale, l’agente deve generare una Certificate Signing Request (CSR) per il dominio desiderato e inviarla all’Autorità di Certificazione (CA). Tutto il processo si svolge in modo sicuro tramite protocollo HTTPS, garantendo integrità e riservatezza delle informazioni.

• L’agente genera un CSR per il dominio
  La prima fase consiste nella creazione della Certificate Signing Request, che include i dati identificativi del dominio (ad esempio example.com) e la chiave pubblica che sarà associata al certificato. Questo documento è il punto di partenza del processo di validazione.

• L’agente firma la chiave pubblica generata insieme al CSR con la corrispondente chiave privata
  Per garantire che la chiave pubblica sia effettivamente legata al dominio e non sia stata alterata, l’agente utilizza la propria chiave privata per firmare il CSR. Questa operazione stabilisce un legame crittografico sicuro tra la coppia di chiavi pubblica/privata.

• L’agente firma l’intero CSR con la propria chiave privata di autorizzazione
  Oltre alla firma legata alla coppia di chiavi del dominio, l’agente applica anche la chiave privata di autorizzazione, generata durante la configurazione iniziale del protocollo ACME. Questa seconda firma serve a dimostrare alla CA che la richiesta proviene da un client legittimo e autorizzato a richiedere certificati.

• La CA verifica entrambe le firme ed emette il certificato
  L’Autorità di Certificazione controlla la validità delle firme, la correttezza del CSR e l’associazione con il dominio. Una volta completate con successo queste verifiche, procede all’emissione del certificato digitale SSL/TLS.

• L’agente riceve il certificato e lo installa sul dominio pertinente
  Dopo l’emissione, il certificato viene trasmesso all’agente, che provvede a installarlo nella configurazione del server. Da questo momento il dominio è accessibile tramite connessioni sicure HTTPS, con il certificato valido e riconosciuto dai browser e dai client.

Ci si rende conto che l’agente di cui stiamo parlando non è certo un ometto che risiede sul vostro server, come le icone che ho scelto potrebbero far pensare. Quindi, non c’è bisogno di sottolinearlo. È solo più divertente immaginarlo in questo modo.

In ogni caso, questo processo si svolge più o meno allo stesso modo anche con i rinnovi. L’agente può essere configurato per inviare un ping alla CA a intervalli regolari per ruotare le chiavi o sostituire interi certificati. E tutto questo avviene dietro le quinte, senza bisogno di alcun intervento umano.

Revoca

Così come avviene per l’emissione, anche la revoca di un certificato SSL/TLS richiede l’intervento dell’agente, che deve generare e firmare una richiesta ufficiale. In questo caso, però, la richiesta non riguarda l’ottenimento di un nuovo certificato ma l’invalidazione di uno già emesso. L’Autorità di Certificazione (CA) procede quindi alla revoca e aggiorna i registri pubblici che permettono ai browser e ai client di controllare lo stato del certificato.

• L’agente genera una richiesta di revoca per il certificato SSL/TLS
  L’agente crea un documento che identifica il certificato da revocare, includendo il numero di serie e le informazioni necessarie per collegarlo univocamente all’emissione originaria.

• L’agente firma la richiesta con la sua chiave privata
  Per assicurare che la richiesta provenga effettivamente dal titolare del certificato, l’agente utilizza la propria chiave privata per firmarla digitalmente. Questa operazione dimostra alla CA che la revoca non è stata richiesta da soggetti terzi non autorizzati.

• La CA verifica la firma per garantire che la richiesta sia autorizzata
  L’Autorità di Certificazione controlla la validità della firma e la corrispondenza con la chiave pubblica associata al certificato. Se la verifica va a buon fine, la CA riconosce la richiesta come legittima.

• La CA revoca il certificato
  Una volta confermata l’autenticità della richiesta, il certificato viene revocato ufficialmente, risultando non più valido per stabilire connessioni sicure.

• Lo stato di revoca del certificato viene pubblicato su CRL e risponditori OCSP
  Infine, la CA aggiorna le Certificate Revocation List (CRL) e i risponditori Online Certificate Status Protocol (OCSP). Questi sistemi permettono a browser e client di verificare in tempo reale lo stato di validità del certificato, garantendo che eventuali certificati compromessi non possano più essere utilizzati per connessioni HTTPS affidabili.

Workflow ACME in NGINX

Il flusso di lavoro ACME all’interno di NGINX può essere descritto come una sequenza di quattro fasi principali, che consentono di gestire in maniera automatizzata l’intero ciclo di vita dei certificati digitali:

1. Impostazione del server ACME
   In questa fase NGINX viene configurato per comunicare con un’Autorità di Certificazione che supporta il protocollo ACME. Ciò consente di stabilire il punto di riferimento da cui richiedere, convalidare e ottenere i certificati SSL/TLS.

2. Allocazione della memoria condivisa
   Per garantire efficienza e stabilità, il modulo ACME di NGINX utilizza aree di memoria condivisa, necessarie a gestire le informazioni relative alle richieste e agli stati di validazione. Questa architettura permette un coordinamento affidabile tra i vari processi del server.

3. Configurazione delle challenge
   NGINX viene istruito a gestire le sfide di validazione richieste dalla CA, come HTTP-01 o DNS-01. Questa fase è fondamentale per dimostrare la proprietà del dominio e autorizzare l’emissione del certificato.

4. Emissione e rinnovo dei certificati
   Una volta completata la validazione, il certificato viene rilasciato e installato automaticamente. Il modulo ACME si occupa anche del rinnovo periodico, eliminando la necessità di interventi manuali e riducendo il rischio di interruzioni del servizio dovute a certificati scaduti.

Impostazione del server ACME

Per abilitare le funzionalità ACME in NGINX, il primo passo – e l’unico obbligatorio – consiste nello specificare l’URL della directory del server ACME. Questo parametro indica al modulo quale Autorità di Certificazione contattare per l’emissione, la convalida e il rinnovo dei certificati SSL/TLS.

Oltre a questo requisito minimo, è possibile definire ulteriori informazioni utili al corretto funzionamento del modulo. Ad esempio, si possono specificare i dati di contatto da utilizzare nel caso in cui l’Autorità di Certificazione debba comunicare problemi legati ai certificati rilasciati. È inoltre possibile configurare il percorso in cui memorizzare i dati del modulo, come le informazioni di stato o le chiavi necessarie al processo di validazione. Queste opzioni aggiuntive, pur non essendo obbligatorie, contribuiscono a rendere la gestione più affidabile e a garantire un migliore controllo operativo.

acme_issuer letsencrypt {
uri https://acme-v02.api.letsencrypt.org/directory;
# contact admin@example.test;
state_path /var/cache/nginx/acme-letsencrypt;

accept_terms_of_service;
}

Allocazione della memoria condivisa

L’implementazione del supporto ACME in NGINX introduce anche la direttiva opzionale acme_shared_zone, pensata per gestire in un’area comune i certificati, le chiavi private e i dati relativi alle challenge provenienti da tutti gli issuer configurati. Questa zona di memoria condivisa permette ai diversi processi del server di accedere in maniera coerente alle stesse informazioni, evitando ridondanze e semplificando il coordinamento interno.

Per impostazione predefinita, la dimensione della zona è pari a 256 KB, un valore sufficiente per scenari semplici. Tuttavia, in ambienti più complessi o con un numero elevato di certificati da gestire, è possibile aumentare questa dimensione in base alle esigenze. La possibilità di regolare la memoria dedicata rende l’approccio più flessibile, assicurando che NGINX possa adattarsi tanto a installazioni leggere quanto a contesti enterprise con requisiti più intensivi.

acme_shared_zone zone=acme_shared:1M;

Configurazione delle challenge

Nella versione di anteprima, l’implementazione ACME in NGINX supporta attualmente le challenge HTTP-01, utilizzate per verificare la proprietà del dominio da parte del client. Per gestire correttamente questo meccanismo è necessario definire, nella configurazione di NGINX, un listener sulla porta 80, in grado di ricevere e rispondere alle richieste di validazione inviate dall’Autorità di Certificazione. Questa configurazione assicura che il server possa dimostrare in modo automatico e trasparente il controllo sul dominio, condizione indispensabile per l’emissione del certificato SSL/TLS.

server {
# Listener on port 80 is required to process ACME HTTP-01 challenges
listen 80;

location / {
# Serve a basic 404 response while listening for challenges
return 404;
}
}

Il team di sviluppo ha inoltre previsto l’estensione del supporto ad altri tipi di challenge, tra cui TLS-ALPN-01 e DNS-01, che saranno introdotti nelle prossime versioni. Questi metodi aggiuntivi amplieranno le possibilità di validazione, offrendo maggiore flessibilità in scenari complessi come l’uso di bilanciatori di carico, ambienti multi-server o contesti in cui l’accesso diretto alla porta 80 non è praticabile.

Emissione e rinnovo dei certificati

Per automatizzare l’emissione e il rinnovo dei certificati TLS in NGINX è possibile utilizzare la direttiva acme_certificate all’interno del relativo server block. Questa direttiva richiede l’elenco degli identifier (i domini) per i quali i certificati devono essere generati in modo dinamico. L’elenco viene in genere definito tramite la direttiva server_name, che specifica i nomi di dominio associati al blocco server.

Un esempio tipico consiste nella configurazione di un server block per il dominio example.domain, sfruttando l’issuer ACME precedentemente definito (ad esempio quello di Let’s Encrypt). In questo scenario, il modulo si occupa automaticamente di richiedere e installare il certificato SSL/TLS, oltre a gestirne i rinnovi periodici, senza la necessità di interventi manuali.

server {
listen 443 ssl;
server_name .example.com;

acme_certificate letsencrypt;

ssl_certificate $acme_certificate;
ssl_certificate_key $acme_certificate_key;
ssl_certificate_cache max=2;
}

È importante sottolineare che non tutti i valori accettati dalla direttiva server_name sono considerati validi identifier. Nella versione di anteprima non è previsto il supporto ai wildcard (ad esempio *.example.domain) né l’uso di espressioni regolari. Questi limiti verranno progressivamente rivisti nelle implementazioni future per ampliare la compatibilità con scenari più complessi.

Una volta ottenuto il certificato, le informazioni relative possono essere gestite tramite le variabili $acme_certificate e $acme_certificate_key, che mettono a disposizione del modulo i dati necessari per abilitare la crittografia SSL/TLS sul dominio associato. Questa integrazione semplifica il flusso operativo e garantisce una gestione uniforme dei certificati direttamente all’interno della configurazione NGINX.

Perché tutto questo è importante

La diffusione globale di HTTPS è stata accelerata in maniera decisiva dall’introduzione del protocollo ACME, che ha reso la sicurezza web un requisito di base e non più un’opzione. Automatizzando l’intero ciclo di vita dei certificati SSL/TLS – dall’emissione al rinnovo fino alla gestione quotidiana – ACME ha eliminato gran parte della complessità operativa e dei costi legati ai processi manuali, rendendo più semplice e accessibile la protezione delle comunicazioni online.

Il ruolo di ACME non si limita al web tradizionale. Con la crescita esponenziale di dispositivi IoT, servizi API e infrastrutture di edge computing, il protocollo si sta affermando come elemento fondamentale anche nell’automazione della sicurezza in contesti distribuiti e altamente scalabili. In tali scenari, la capacità di fornire certificati affidabili e sempre aggiornati rappresenta un requisito cruciale per garantire integrità, privacy e resilienza dei sistemi.

Il supporto nativo ad ACME all’interno di NGINX conferma l’importanza strategica di questo protocollo per il futuro della sicurezza, dell’automazione e della scalabilità. Tutto lascia prevedere che ACME rimarrà per lungo tempo il pilastro dell’automazione dei certificati, estendendo il suo impatto ben oltre il web. Poiché la sicurezza è ormai parte integrante degli standard di rete, è naturale attendersi una continua evoluzione sia nei modelli di distribuzione delle applicazioni sia nei requisiti di protezione, spingendo a ulteriori miglioramenti e rafforzamenti del protocollo stesso.

Guardando al futuro, il team di sviluppo di NGINX ha espresso l’impegno a far crescere progressivamente la propria implementazione, così da allinearsi non solo alle esigenze attuali di utenti e clienti, ma anche a quelle emergenti. L’obiettivo è fornire funzionalità che siano pronte ad affrontare i nuovi scenari, con un approccio capace di bilanciare affidabilità, sicurezza e innovazione.

Come iniziare

È già possibile sperimentare il supporto nativo ad ACME in NGINX.

• Per gli utenti open source, sono disponibili pacchetti precompilati scaricabili.

• Per i clienti enterprise di NGINX Plus, attraverso la piattaforma NGINX One, il modulo è fornito come componente dinamico supportato da F5.

Ulteriori informazioni sulla configurazione e sull’utilizzo del modulo sono disponibili nella documentazione ufficiale di NGINX.