Let’s Encrypt ACME: automatizzare i certificati e gestire in modo sicuro i rinnovi

Procedura ACME e ruoli separati per le chiavi

ACME standardizza la comunicazione tra un client e l’autorità di certificazione, non l’intero ambiente operativo. Il client utilizza innanzitutto un account ACME e crea quindi un ordine per uno o più nomi di dominio. Per ogni identificatore, il server richiede un'autorizzazione. Solo una volta ottenuta l'autorizzazione, il client può finalizzare l'ordine con una Certificate Signing Request (CSR) e recuperare il certificato emesso.

1. Generare una chiave dell'account oppure utilizzare un account ACME esistente e creare l'ordine.
2. Per ogni identificatore richiesto, fornire la sfida specificata e attendere l'autorizzazione.
3. Generare una coppia di chiavi separata per il certificato, creare la CSR a partire da essa e finalizzare l'ordine. La chiave pubblica nella CSR non deve coincidere con la chiave dell'account che autentica l'ordine di finalizzazione.
4. Recuperare il certificato e la catena di certificati, archiviarli in modo sicuro e distribuirli agli endpoint TLS previsti.

Il sito Codice account ACME autentica il client per l'account nei confronti del server ACME e firma i messaggi di protocollo. La chiave privata utilizzata nella CSR appartiene invece alla successiva identità TLS. La RFC 8555 richiede due classi di chiavi distinte: la chiave pubblica della CSR non deve corrispondere a una chiave di account nota e, in particolare, non deve essere identica alla chiave di account che autentica la richiesta di finalizzazione. Il client e il server devono verificare tale separazione.

Nel caso di DNS-01 si aggiunge un terzo elemento sensibile: l’autorizzazione per l’API DNS. Let’s Encrypt sottolinea che la presenza di credenziali complete per l’API DNS su un server web aumenta notevolmente le conseguenze di un attacco. Come misura di sicurezza operativa, il token dovrebbe quindi essere autorizzato a modificare solo i record di challenge necessari; in alternativa, la convalida DNS può essere eseguita su un sistema separato.

Le chiavi dell’account, le chiavi del certificato e l’accesso al DNS costituiscono ambiti di fiducia distinti. L’utilizzo di coppie di chiavi diverse per l’account e il certificato è un requisito del protocollo; la loro archiviazione separata, i diritti di accesso strettamente limitati e i processi di rotazione indipendenti costituiscono inoltre importanti misure operative. In questo modo, un token DNS compromesso non comporta necessariamente l’accesso né alla chiave privata del certificato né all’account ACME.

L’automazione non elimina i presupposti errati. Una porta non raggiungibile, un routing errato, una delega DNS inadeguata o diritti di accesso troppo estesi rimangono problemi operativi, anche se la creazione degli ordini è automatizzata. ACME accelera il flusso di lavoro ripetibile; gli operatori devono implementare in modo affidabile nel proprio ambiente un modello di autorizzazioni, la separazione obbligatoria tra chiavi di account e chiavi di certificato, l’archiviazione sicura e il controllo dei certificati effettivamente emessi.

La sfida giusta per l'infrastruttura

La sfida determina il modo in cui un’autorità di certificazione verifica il controllo su un identificatore. Dovrebbe quindi derivare dal percorso di rete, dalla gestione DNS e dalla terminazione TLS, non da una preferenza generica per uno strumento client. HTTP-01, DNS-01 e TLS-ALPN-01 prevedono diversi tipi di verifica e pongono, di conseguenza, requisiti diversi in termini di infrastruttura e autorizzazioni.

Per un singolo sito web accessibile al pubblico, è HTTP-01 di solito il percorso più diretto. Il client mette a disposizione una risorsa sotto /.well-known/acme-challenge/ pronta, che recupera Let’s Encrypt tramite la porta 80. Se un dominio punta a più destinazioni A o AAAA, questa risorsa deve essere accessibile su tutti i sistemi che possono ricevere la richiesta di convalida. In caso contrario, si verifica un errore di convalida che si presenta solo occasionalmente.

Certificati Wildcard per *.example.org richiedono invece obbligatoriamente DNS-01. A tal fine, il client pubblica un record TXT all'indirizzo _acme-challenge.example.org. Ciò è adatto a molti sottodomini dinamici, server web distribuiti o a un bilanciatore di carico, poiché nessuna singola istanza HTTP deve fornire il file di convalida. È tuttavia necessario che la modifica del DNS sia affidabile e automatizzabile.

Un proxy inverso senza una porta 80 utilizzabile può TLS-ALPN-01 utilizzarlo, a condizione che controlli la terminazione TLS sulla porta 443 e che il client utilizzato supporti questa challenge. La convalida avviene tramite una connessione TLS dedicata, non tramite un normale file web. La procedura è quindi particolarmente adatta per infrastrutture proxy o di hosting specializzate, ma non come sostituto generico di HTTP-01. Anche in questo caso non sono supportati i caratteri jolly.

Nessun metodo è generalmente superiore: HTTP-01 riduce l’accesso al DNS nel caso di un sito web semplice, DNS-01 consente l’uso di caratteri jolly e separa la convalida dal percorso web, mentre TLS-ALPN-01 sfrutta in modo mirato i controlli TLS esistenti. È fondamentale che la sfida scelta funzioni in condizioni reali di failover e lungo i percorsi IPv4 e IPv6 e che le sue autorizzazioni siano adeguate al rispettivo modello operativo.

ARI, profili e durate più brevi

Con Informazioni sul rinnovo ACME (ARI) la logica di rinnovo passa da una data di scadenza fissata a livello locale a una finestra temporale raccomandata dal server ACME. Il client richiede queste informazioni per un certificato esistente e sceglie un momento casuale all’interno di tale finestra temporale. In questo modo è possibile distribuire i rinnovi nel tempo e, in caso di eventi particolari, anticiparli in modo mirato.

ARI è un’estensione standardizzata, ma non è una funzionalità automatica di ogni client o pannello di hosting installato. Let’s Encrypt può offrire nuove funzionalità ACME retrocompatibili sull’endpoint esistente; il fatto che una specifica installazione le utilizzi dipende dalla sua versione e dall’implementazione. Per i parchi server di grandi dimensioni è quindi necessario verificare se il client interroga ARI, rispetta la finestra temporale e non risincronizza i rinnovi.

Let’s Encrypt assegna inoltre i certificati a determinati profili. Se non si seleziona espressamente un profilo, viene applicato il profilo classico come impostazione predefinita, che attualmente ha una validità di 90 giorni. Il profilo tlsserver ha una durata di 45 giorni, scadenze più brevi per le autorizzazioni e gli ordini aperti e un massimo di 25 nomi DNS. shortlived utilizza anch’esso periodi di validità brevi per gli oggetti, ha una validità di circa 160 ore e supporta gli identificatori DNS e IP.

Anche la selezione dei profili richiede il supporto da parte del client; non dovrebbe essere dedotta esclusivamente dalla documentazione del server. Oltre alla durata e agli identificatori, i profili si differenziano anche per altre caratteristiche. Le applicazioni e gli strumenti di inventario non devono quindi presupporre tacitamente né un flusso di lavoro uniforme né la presenza di un Common Name in ogni certificato.

Da un punto di vista matematico, tra 90 giorni e circa 160 ore si ha un fattore di circa 13,5 in termini di durata. Da ciò non deriva un carico misurabile, ma una chiara conseguenza in termini di pianificazione: qualsiasi problema relativo all’ordine, alla distribuzione o al rifornimento comporta certificati a breve durata molto prima in modo critico. Sono utili solo per sistemi la cui catena di fornitura sia interamente monitorata e il cui rinnovo non dipenda da interventi manuali. Per i rinnovi coordinati da ARI, Let’s Encrypt applica regole speciali relative ai limiti di richiesta, in base a condizioni documentate.

Matrice delle sfide e delega sicura del DNS

La scelta della sfida dipende dall’infrastruttura disponibile, non da una classifica generale. HTTP-01 richiede una risposta accessibile pubblicamente sulla porta 80, DNS-01 un record TXT verificabile e TLS-ALPN-01 il controllo sulla terminazione TLS sulla porta 443. I nomi con caratteri jolly possono essere convalidati esclusivamente con DNS-01.

Un sito web con un unico server web è quindi spesso ben gestito con HTTP-01. Tuttavia, se i record DNS A o AAAA puntano a più sistemi, ogni destinazione effettivamente raggiunta deve fornire la risorsa prevista. In caso contrario, il risultato dipende dall’endpoint raggiunto dalla convalida. Un bilanciatore di carico o un archivio di challenge sincronizzato centralmente risolve questo problema solo se copre tutti i percorsi.

Per il DNS-01 è previsto come Autorizzazione minima L'obiettivo è garantire che il client ACME possa modificare solo le voci di challenge necessarie. La limitazione effettivamente possibile dipende dall'API e dal modello di autorizzazione del provider DNS; non tutti i servizi consentono di assegnare diritti per un singolo nome TXT. Se rimane solo un accesso di ampia portata, la convalida dovrebbe essere trasferita su un sistema separato oppure dovrebbe essere delegata una zona di sfida distinta. I dati di accesso devono essere conservati in un archivio protetto, separatamente dalle chiavi dei certificati e dall’account ACME.

Nel caso di zone di grandi dimensioni, una zona “Challenge” separata può limitare ulteriormente i diritti. La delega di _acme-challenge Tramite CNAME o NS, i dati di convalida vengono trasferiti in un’area amministrativa dedicata. Il client avrà quindi diritti di modifica solo in quell’area. Prima dell’utilizzo in produzione, è necessario verificare il contenuto del record TXT e la risoluzione DNS: una risposta API corretta non è sufficiente se i resolver non rilevano ancora la delega o il record.

Automatizzare in modo affidabile l'aggiornamento e la distribuzione

Resistente Gestione dei certificati non si esaurisce con il recupero di un certificato. In un ambiente distribuito, un worker ACME centrale avvia la convalida e archivia in modo protetto sia il certificato che la chiave privata. Solo successivamente gli artefatti vengono distribuiti agli endpoint TLS, dove vengono verificati e attivati in modo controllato. La chiave del certificato utilizzata nella CSR deve essere diversa dalla chiave dell’account ACME utilizzata per l’autenticazione; le modalità con cui entrambe le chiavi vengono successivamente archiviate separatamente, autorizzate e sottoposte a rotazione devono essere definite nel piano operativo.

La tabella seguente descrive un modello operativo raccomandato per la catena di fornitura. La RFC 8555 richiede che la chiave pubblica della CSR non corrisponda a nessuna chiave di account nota e, in particolare, non coincida con la chiave di account utilizzata per l’autenticazione dell’ordine di finalizzazione. La separazione organizzativa concreta tra archiviazione, diritti di accesso e rotazione si basa su questo requisito del protocollo. Il Deploy Hook di Certbot è previsto per le azioni successive al rilascio riuscito. La sicurezza della trasmissione, la verifica della destinazione e il controllo TLS esterno devono essere adeguati alla rispettiva infrastruttura.

Per le modifiche alle integrazioni con Panel o DNS, la catena produttiva non dovrebbe essere considerata come un sistema a sé stante. In particolare, in caso di gestione tramite Aggiornamenti di Plesk per i fornitori di servizi di hosting Le funzioni disponibili dipendono dal Panelstand, dalle estensioni e dai servizi collegati. Anche la capacità concreta del client ACME, ad esempio per ulteriori estensioni di protocollo, dipende dalla versione e deve essere verificata nella combinazione utilizzata.

In Certbot, un deploy hook può attivare l'ultimo passaggio, poiché viene eseguito solo dopo un rinnovo riuscito. Il modello seguente presuppone che il percorso locale sia uno script verificato ed eseguibile privo di credenziali. Lo script dovrebbe idempotente lavorare, registrare gli errori e ricaricare esclusivamente i servizi che utilizzano il certificato aggiornato.

certbot renew --deploy-hook /usr/local/sbin/reload-tls-services

Lo stato di uscita di certbot renew non costituisce una prova dell'esistenza di un nuovo certificato: anche se non c'era nulla da rinnovare, il comando può terminare con lo stato 0. Il sistema di monitoraggio deve quindi verificare autonomamente quale certificato venga effettivamente fornito dall'endpoint pubblico, quando scade e se il ricaricamento è andato a buon fine.

CAA, profili e certificati per gli indirizzi IP

Un record CAA è un Ringhiera espositiva: Stabilisce quali autorità di certificazione sono autorizzate a rilasciare certificati per un dominio. Inoltre, la politica può specificare il metodo di convalida consentito e, tramite il parametro accounturi Specificare l'account ACME previsto. La chiave dell'account corrente autentica l'accesso a tale account, ma può essere modificata tramite il processo di cambio chiave ACME. Il collegamento all'account non sostituisce quindi né la protezione offerta dalla chiave dell'account corrente né un sistema completo di autorizzazioni.

La seguente riga di record consente l’utilizzo di Let’s Encrypt per il dominio solo con la convalida DNS-01. È adatta solo se DNS-01 è configurato in modo automatizzato e la zona di challenge è gestita in modo affidabile. Chi in seguito intenda utilizzare HTTP-01 per un singolo sito web o TLS-ALPN-01 per un proxy inverso, bloccherà consapevolmente l’emissione del certificato con la restrizione indicata.

example.org. CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

La singola riga non descrive necessariamente la completa Politica CAA della zona. Più record dello stesso tipo hanno effetto cumulativo: se uno di essi autorizza l’emissione, tale autorizzazione può sussistere nonostante l’esistenza di altri record con criteri più restrittivi. Per i certificati con caratteri jolly occorre inoltre verificare se issuewild- sono presenti record. In assenza di tali record, vale issue anche per i caratteri jolly; esistenti issuewild-Le voci regolano invece separatamente l'emissione dei simboli jolly. È quindi sempre determinante la serie completa di record validi relativa al nome verificato.

I certificati per indirizzi IP pubblici sono un caso a sé rispetto ai certificati di dominio. Let’s Encrypt supporta gli identificatori IP nel profilo shortlived; come metodi di convalida sono disponibili HTTP-01 e TLS-ALPN-01. DNS-01 non è in grado di convalidare un indirizzo IP. La breve durata di validità, pari a circa 160 ore, richiede pertanto un processo continuo e automatizzato di rinnovo, distribuzione e controllo della consegna.

Il profilo "shortlived" è quindi adatto, ad esempio, per interfacce raggiungibili direttamente tramite IP solo se ogni fase funziona senza interventi manuali. Non si tratta di una variante semplificata per sistemi sottoposti a manutenzione occasionale. Inoltre, il client ACME utilizzato e l’ambiente di destinazione devono supportare sia la scelta del profilo che la challenge selezionata; la disponibilità sul servizio ACME non garantisce il supporto da parte di ogni versione del client.

Monitoraggio e ricerca dei guasti innanzitutto nell'ambiente di staging

La ricerca degli errori in ACME inizia con la procedura di convalida effettivamente utilizzata, non con una nuova richiesta di certificato. Per le modifiche al client, al routing, al firewall o al DNS è indicato l’endpoint di staging separato di Let’s Encrypt. L’ambiente di staging ha limiti propri, nettamente più elevati, ma non è illimitato; i certificati di prova emessi in tale ambiente non sono considerati affidabili pubblicamente. Sebbene le nuove funzionalità del protocollo possano essere disponibili sull’endpoint ACME, è comunque necessario verificare separatamente la compatibilità del client installato.

Nel caso di HTTP-01, occorre innanzitutto verificare se il dominio in questione sia accessibile pubblicamente tramite la porta 80 e se il file richiesto si trovi all'indirizzo /.well-known/acme-challenge/ al sistema di destinazione. La presenza di più record A o AAAA rende il test più complesso: ogni endpoint effettivamente raggiungibile deve fornire il file di sfida corrispondente. Le cause tipiche sono un routing dell’host virtuale non corretto, un proxy a monte, una regola del firewall o container non sincronizzati.

TLS-ALPN-01 richiede invece il controllo sulla terminazione TLS sulla porta 443. In caso di errore, occorre verificare quale load balancer o proxy accetti la connessione, se fornisca il certificato necessario per la challenge e se un servizio TLS regolare sovrascriva l’operazione. La creazione riuscita di un file di certificato locale non dimostra che l’endpoint pubblico a cui ci si rivolge lo stia effettivamente utilizzando.

Per DNS-01, il nome e il contenuto del record TXT si trovano in _acme-challenge da controllare separatamente. Il record deve essere pubblicato nella zona delegata o di riferimento; inoltre, se si utilizza una zona di challenge separata, la catena di delega deve essere corretta. I ripetuti tentativi falliti dovuti a errori di digitazione, modifiche non ancora visibili o delega errata dovrebbero essere analizzati innanzitutto nell'ambiente di staging.

Efficace Monitoraggio Non si limita a monitorare la data di scadenza nell’archivio dell’ACME Worker. Verifica in modo indipendente il nome host fornito, la durata residua del certificato ivi presente e l’esito positivo del ricaricamento dopo un aggiornamento. Dovrebbe essere generato un allarme anche se un rinnovo fallisce o se un endpoint continua a fornire il vecchio certificato nonostante l’emissione sia avvenuta con successo. Per le modifiche pianificate ai server di hosting, l’articolo integra Pianificare in modo sicuro gli aggiornamenti di cPanel e WHM la necessaria pianificazione operativa.

Limiti di tasso e rinnovi nel portafoglio

In un portafoglio di certificati, i limiti di quota costituiscono una condizione di progettazione del Automazione SSL. Gli aggiornamenti forzati giornalieri o i processi avviati contemporaneamente generano ordini superflui e possono far scattare dei limiti. Ciò vale in particolare quando un errore dell’infrastruttura interessa contemporaneamente molti domini: le ripetizioni non risolvono né la mancanza di file di challenge né un DNS errato, ma aumentano il numero di convalide fallite. Gli errori devono quindi essere circoscritti prima della successiva esecuzione in produzione.

Informazioni sul rinnovo ACME, in breve ARI, sostituisce i valori soglia locali fissi con una finestra di rinnovo raccomandata dal server ACME per un certificato esistente. Il client compatibile con ARI richiede le informazioni di rinnovo e sceglie un momento casuale all’interno di tale finestra. Uno scheduler può avviare il client a intervalli regolari, ma non valuta direttamente le informazioni ARI. Il client deve utilizzare la finestra raccomandata e Retry-After tenerne conto e, in caso di errori, rispettare intervalli di backoff e di ripetizione adeguati. Un’esecuzione più frequente dello scheduler non deve quindi portare a ripetizioni incontrollate di operazioni fallite.

Per Let’s Encrypt, i rinnovi coordinati da ARI possono essere esclusi dai limiti di frequenza (rate limit) secondo i requisiti documentati. La nuova richiesta deve contenere, tra l’altro, almeno un identificatore del certificato da sostituire, e quest’ultimo non deve essere già stato sostituito tramite ARI. Ciò non costituisce un’autorizzazione generale per qualsiasi nuova richiesta: le modifiche all’ambito del certificato devono essere trattate separatamente dal punto di vista tecnico e operativo.

In particolare, un elenco SAN abbreviato o modificato non comporta automaticamente il rinnovo del certificato precedente. Una richiesta che includa solo una parte dei nomi precedenti può generare un certificato separato, mentre quello vecchio rimane valido. L’inventario dovrebbe quindi includere l’ID del certificato, l’elenco completo degli identificatori, gli endpoint associati e la procedura di rinnovo. Prima di una modifica pianificata della SAN, è necessario decidere quali servizi devono essere aggiornati e quando rimuovere i certificati non più necessari.

In presenza di più worker, l’assegnazione univoca delle responsabilità impedisce la duplicazione degli ordini per lo stesso stock. È opportuno ricorrere a uno scheduler centrale o a un blocco coordinato, a registri tracciabili e a ripetizioni scaglionate in caso di errore. La selezione casuale all’interno di una finestra ARI non sostituisce questo controllo, ma riduce soprattutto la simultaneità degli aggiornamenti regolari.

Scegliere il modello operativo più adatto in base al rischio

Per un singolo sito web accessibile al pubblico, HTTP-01 rappresenta solitamente il modello operativo più semplice. Il server web deve gestire in modo affidabile la porta 80 e fornire il file di challenge nel percorso previsto. Questo modello non è compatibile con i caratteri jolly e diventa instabile quando più destinazioni indipendenti rispondono allo stesso dominio. È quindi particolarmente indicato quando il routing web, l’archiviazione dei certificati e la distribuzione TLS convergono in un unico punto chiaramente controllato.

DNS-01 è il modello ideale per i caratteri jolly, i sottodomini dinamici e gli endpoint TLS distribuiti. Il requisito fondamentale non è semplicemente la possibilità di accedere al DNS, bensì la possibilità di modificare in modo sicuro e automatizzato il record TXT necessario. Un token il più possibile limitato o una zona di challenge delegata riducono le conseguenze della compromissione di un sistema. Il livello di granularità raggiungibile dipende dall’API DNS. Le deleghe devono essere documentate come dipendenza operativa, monitorate e dotate di una procedura di ripristino.

TLS-ALPN-01 è adatto agli operatori che desiderano controllare in modo mirato la terminazione TLS sulla porta 443, ad esempio su un proxy inverso o un bilanciatore di carico. Questo metodo non costituisce un sostituto generico di HTTP-01 né supporta i caratteri jolly. La sua utilizzabilità pratica dipende inoltre dalla specifica implementazione del client e del proxy. Prima dell’utilizzo è quindi necessario verificare se il software è in grado di generare la challenge, inviarla e rimuoverla correttamente al termine del processo.

Il sito Profilo shortlived È adatto solo a sistemi con automazione end-to-end completa. Let’s Encrypt indica a tal fine una durata di circa 160 ore, oltre a identificatori DNS e IP; rispetto al profilo standard di 90 giorni, ciò aumenta notevolmente, in termini matematici, la frequenza di rinnovo necessaria. Ogni fase, dall’ordine alla distribuzione, al ricaricamento e alla verifica esterna, deve quindi funzionare in modo affidabile. La scelta di un profilo presuppone inoltre che il client ACME utilizzato supporti effettivamente la selezione del profilo.

Indipendentemente dal modello, è necessario un Gestione dei certificati un inventario completo, chiavi gestite in modo sicuro e accessi DNS con autorizzazioni minime. La chiave dell’account autentica il client per l’account ACME; la chiave privata utilizzata nella CSR appartiene all’identità TLS. L’RFC 8555 vieta l’utilizzo della chiave pubblica dell’account in un certificato: in particolare, la chiave presente nella CSR non deve coincidere con la chiave dell’account che autentica l’ordine di finalizzazione. L’archiviazione separata, l’assegnazione dei diritti e la rotazione di queste classi di chiavi, nonché gli accessi revocabili e un percorso di ritorno testato al certificato precedente, fanno parte del concetto di gestione dei diritti e delle emergenze.

L'esecuzione corretta di ACME non deve essere l'unico criterio di successo. Il controllo di distribuzione deve verificare, al di fuori del worker, quale certificato venga presentato da un vero endpoint TLS. Per le fasi di distribuzione e ricaricamento sono indicate azioni che vengono attivate solo dopo un rinnovo riuscito; in Certbot è previsto a tal fine un deploy hook. Il suo script dovrebbe essere idempotente, registrare gli errori e ricaricare solo i servizi che utilizzano effettivamente il materiale rinnovato.