Rinnovo dei certificati SSL/TLS: automazione, casi ribelli e soglia d'acquisto

⚡TL;DR

• I rinnovi non consumano la quota Let's Encrypt di 50 certificati per dominio registrato. Questo limite misura l'ingresso di nuovi nomi, non la dimensione di un parco. Credere il contrario falsa qualsiasi dimensionamento.
• Ciò che rompe un rinnovo di certificato SSL non è quasi mai ACME, ma gli endpoint che nessuno script ricarica: apparati con interfaccia web, keystore con password interattiva, terminazioni TLS gestite senza API.
• Un inventario si tiene per coppia (host, porta), non per nome host. Sullo stesso indirizzo IP, ldap.google.com restituisce a un client predefinito due numeri di serie diversi sulle porte 389 e 636, e uno scanner che dimentica l'SNI registra un terzo serial, stabile e falso.
• ACME, ARI e le sei fasi del ciclo di vita sono qui dati per acquisiti: sono trattati nella guida alla gestione del ciclo di vita dei certificati.

Il rinnovo di un certificato SSL fallisce raramente dove te lo aspetti. La modalità di guasto più comune non è un errore di emissione ben visibile in un log: è un certbot renew che gira verde per settimane mentre il servizio continua a presentare il vecchio certificato. Due righe di openssl lo rilevano: il numero di serie letto sul disco contro quello realmente servito sulla porta. Nulla, nei log del client ACME, lo farà al posto tuo. Gli output reali sono più avanti.

Il contesto irrigidisce la meccanica. Al 21 luglio 2026, un certificato TLS pubblico non può superare i 200 giorni di validità, e lo stesso limite si applica al riutilizzo della validazione del controllo del dominio. Le fasi successive scattano a marzo 2027 e poi a marzo 2029, e la seconda disaccoppia validità e rivalidazione. Il perché di questo calendario è trattato nel nostro articolo sulla riduzione a 47 giorni. Qui parliamo del come: cosa si rompe concretamente quando la frequenza sale, e cosa mettere in campo.

Questo playbook si rivolge ai team che gestiscono tra 50 e 1000 certificati su un parco eterogeneo, senza un team PKI dedicato. Ci troverai comandi realmente eseguiti con i loro output reali, le trappole che li accompagnano, e i punti in cui non abbiamo potuto misurare nulla, detti come tali. Nessun comparativo di vendor. Un solo criterio d'acquisto, quantificato, e non riguarda il numero di certificati.

Scadenza dei certificati SSL nel 2026: la fase in vigore e cosa cambia per i tuoi script

Al 21 luglio 2026, la fase applicabile è quella entrata in vigore il 15 marzo 2026. Fissa tre tetti: 200 giorni di validità massima, 200 giorni di riutilizzo della validazione del controllo del dominio (DCV) e 398 giorni di riutilizzo delle informazioni di identità del sottoscrittore (SII). È il tetto rigido dei Baseline Requirements del CA/Browser Forum.

In pratica, le autorità di certificazione emettono al di sotto. Il testo raccomanda di non superare i 199 giorni e vieta solo oltre i 200, per cui il margine operativo lo prendono tutti. DigiCert ha smesso di accettare richieste di certificati TLS pubblici con validità superiore a 199 giorni il 24 febbraio 2026, circa tre settimane prima della scadenza. Sectigo ha seguito il 12 marzo 2026: 199 giorni di validità per ogni certificato TLS emesso o riemesso, 198 giorni di riutilizzo della DCV.

Il seguito ha già le sue date. Il 15 marzo 2027, la validità massima e il riutilizzo della DCV passano entrambi a 100 giorni. Il 15 marzo 2029, la validità scende a 47 giorni e il riutilizzo della DCV a 10 giorni. Il SII, invece, resta fissato a 398 giorni per tutto il calendario: il suo unico gradino è quello del 15 marzo 2026.

Attenzione alla scorciatoia più diffusa: nel 2029 non è la validità a scendere a 10 giorni, è il riutilizzo della prova di controllo del dominio. I due contatori si separano, ed è proprio lì che cambia tutto per i tuoi script. Oggi una validazione riuscita copre più rinnovi consecutivi. Nel 2029, ogni riemissione si porterà dietro una rivalidazione completa, perché la prova precedente sarà scaduta da tempo. Automatizzare l'emissione non basterà più. Servirà che la validazione sia automatizzata in permanenza, quindi che i diritti di scrittura DNS o l'accesso alla porta 80 siano disponibili in continuo, e non soltanto il giorno in cui una persona pianifica una modifica.

Inventariare un parco di certificati: quattro fonti, quattro punti ciechi

Nessuna fonte di inventario vede l'intero parco. I log di trasparenza elencano ciò che è stato emesso pubblicamente, il disco e gli store elencano ciò che è installato, la scansione di rete legge ciò che viene servito, e le API dei provider coprono ciò che le altre tre non vedono. Vanno incrociate, e soprattutto bisogna sapere cosa ciascuna si perde.

I log di trasparenza mostrano ciò che è stato emesso, non ciò che gira

I log di Certificate Transparency registrano ogni certificato emesso da un'autorità pubblica per i tuoi domini. Non dicono né dove è distribuito, né se è ancora in servizio. La query ingenua sta in una riga:

curl -s 'https://crt.sh/?q=%25.captaindns.com&output=json' | jq -r '.[].name_value' | sort -u

Sul nostro dominio ha restituito 12 valori unici in 54 secondi. Un'esecuzione precedente aveva restituito tre HTTP 502 consecutivi prima di riuscire al quarto tentativo. Niente di rotto nel comando: crt.sh risponde così.

Quel che segue è stato incontrato durante l'esecuzione, non dedotto. Il -s nasconde il fallimento: jq riceve HTML e restituisce jq: parse error: Invalid numeric literal at line 1, column 7, e senza set -o pipefail lo script prosegue come se nulla fosse. I 54 secondi sono un tempo di risposta nominale per 142 certificati, non una limitazione di banda. Il %25 codifica la wildcard %, che copre i sottodomini ma non l'apex. Il campo name_value contiene ritorni a capo quando il certificato porta più SAN: 142 oggetti JSON hanno prodotto 158 righe per 12 valori unici, il che rende obbligatorio il sort -u. Infine, i certificati scaduti sono inclusi di default: 76 delle 142 voci.

La versione irrobustita corregge tutto questo:

curl -sS --fail --retry 8 --retry-all-errors --retry-delay 5 --max-time 180 \
  -o crt.json 'https://crt.sh/?q=%25.captaindns.com&output=json&exclude=expired' \
&& jq -r '.[].name_value' crt.json | sed 's/^\*\.//' | tr 'A-Z' 'a-z' | sort -u

Output reale: codice 0 in 41,9 secondi, nuovi tentativi compresi, 66 voci contro 142 senza il filtro lato server, e 11 nomi. Due varianti sono state testate e scartate, e sono quelle che insegnano di più. Senza -o, con output su stdout, curl concatena il corpo del 502 con quello del 200 riuscito: 8342 byte che iniziano con <html><head><title>502 Bad Gateway</title> seguiti dal JSON valido, e jq fallisce. Con -o, curl riavvolge il file a ogni tentativo. E --fail --retry 8 senza --retry-all-errors non riprova: curl 8.7.1 riporta curl: (56), codice assente dall'elenco degli errori che curl riprova di default. Fallimento in 0,12 secondi.

Resta il punto cieco strutturale: la trasparenza vede solo la PKI pubblica. I tuoi certificati interni non ci compaiono.

Il disco e gli store mostrano ciò che è installato, non ciò che è servito

Leggere un file PEM, un keystore Java o lo store macchina di Windows dice cosa è posato sulla macchina. Non cosa il servizio presenta alla rete.

Lato PEM, openssl x509 -in fullchain.pem -noout -subject -dates -serial basta. Per gli altri due, prima l'onestà: non abbiamo potuto eseguire i comandi corrispondenti. La nostra postazione di test non ha un JDK e non gira su Windows. Invece di un output inventato, ecco la traccia del tentativo:

$ keytool -list -v -keystore /Library/Keychains/System.keychain
The operation couldn't be completed. Unable to locate a Java Runtime.

$ file /usr/bin/keytool
/usr/bin/keytool: Mach-O universal binary with 2 architectures

$ pwsh -NoProfile -Command 'Get-ChildItem Cert:\LocalMachine\My'
Get-ChildItem: Cannot find drive. A drive with the name 'Cert' does not exist.

Questi due fallimenti smontano ciascuno un falso positivo di disponibilità. La macchina espone davvero un binario /usr/bin/keytool, ma è un binario sostitutivo di Apple che rimanda al sito di Java: un which keytool che risponde non prova nulla su macOS. E installare PowerShell 7 su macOS o Linux non dà alcun accesso allo store dei certificati, perché il provider Certificate è un componente Windows assente dall'elenco dei PSProvider. Questo script si valida soltanto sul suo bersaglio.

Le trappole contano quanto i comandi. keytool chiede la password in modo interattivo, e passarla con -storepass la espone nella cronologia e in ps: meglio -storepass:file. Dal JDK 9, il formato predefinito è PKCS12, non JKS. Lato Windows, LocalMachine\My richiede una console aperta come amministratore, altrimenti l'elenco torna troncato senza alcun messaggio di errore, e un binding IIS può puntare a un'impronta diversa da ciò che è installato.

La scansione di rete non vedrà mai i tuoi server di posta

Una scansione di rete legge ciò che viene realmente servito, il che ne fa la fonte più affidabile. Da una postazione ordinaria o dalla maggior parte dei cloud, però, non vedrà mai i tuoi server di posta: la porta 25 in uscita è filtrata.

La prova sta in tre righe, su un solo host. smtp.gmail.com risolveva, al momento del test, verso un unico indirizzo, e i frontend Google ruotano: qualunque sia l'indirizzo restituito dalla risoluzione, le tre porte danno lo stesso contrasto. La porta 587 in STARTTLS e la porta 465 in TLS implicito accettano la connessione e restituiscono il certificato; sulla porta 25 la connessione va in timeout. La macchina è raggiungibile, è la porta a essere bloccata. Ripetuto verso sette MX pubblici di sei operatori diversi, due presso Google, poi Proton, OVH, Riseup, Yandex e GMX, lo stesso comando va in timeout sette volte su sette.

La porta 25 è filtrata da noi, in uscita. La sfumatura conta, perché la conclusione opposta gira ovunque. Google non chiude nulla. AWS, GCP, Azure e OVH bloccano la 25 in uscita di default, così come la quasi totalità degli accessi residenziali. Una scansione del parco lanciata da una macchina di questo tipo produce quindi un risultato meccanicamente incompleto.

Lo stesso sintomo copre però due cause distinte, e la seconda non viene dalla tua rete. Dalla stessa postazione, pop.gmail.com va in timeout sulla porta 110 mentre pop.gmx.net risponde, e imap.gmx.net risponde sulla 143, STARTTLS validato, come sulla 993; la 995 passa ovunque. Le porte in chiaro non sono quindi filtrate in uscita, a differenza della 25: sono gli host Google a scartare quei pacchetti senza risposta, perché non offrono né POP3 né IMAP in chiaro. Policy del provider da un lato, filtraggio della rete dall'altro: due cause di «irraggiungibile», un solo sintomo. Prima di concludere che una porta è filtrata, prova con un secondo operatore.

Uno scanner di inventario deve quindi distinguere tre stati, non due: certificato letto, certificato in errore e host non raggiunto. Un «irraggiungibile» contato come un «nulla da segnalare» è il peggior risultato possibile, perché la dashboard resta verde su servizi che non sono mai stati misurati. E sugli MX la posta in gioco non è teorica: se il certificato cambia prima che il record TLSA corrispondente sia pubblicato, la RFC 7672 vieta la consegna del messaggio tramite quel server e impone al mittente di passare all'MX successivo o di rimandare la consegna.

I nostri stessi strumenti cadono sotto lo stesso limite: il monitor di uptime di CaptainDNS accetta solo gli schemi HTTP e HTTPS. SMTP, IMAPS e LDAPS restano fuori dal suo perimetro.

Le API dei provider vedono ciò che le altre tre fonti collegano male

Resta la quarta fonte, la meno spettacolare: le API dei provider. AWS Certificate Manager, Cloudflare o una CDN che termina il TLS al posto tuo detengono certificati che nient'altro collega correttamente al tuo parco. I log di trasparenza li vedono senza dire chi li opera, il disco non li contiene, e la scansione di rete li attribuisce all'infrastruttura del provider anziché al tuo servizio. L'API è l'unico posto in cui queste terminazioni gestite esistono con la loro data di scadenza e la loro modalità di rinnovo.

Il suo punto cieco è simmetrico: ogni API copre soltanto ciò che vive presso quel provider, e presuppone diritti di lettura che il team che inventaria non sempre ha. Tre provider significano tre interrogazioni, tre set di credenziali e tre formati di risposta da riconciliare.

Un inventario si indicizza su una coppia (host, porta), non su un nome

Stesso nome, stesso indirizzo IP, due certificati. ldap.google.com risolve verso un unico indirizzo IPv4, 216.239.32.58. Un client predefinito ci legge il numero di serie 84D4296C sulla porta 389 in STARTTLS, e E97CCECB sulla porta 636 in TLS implicito. Tre esecuzioni identiche, tre volte lo stesso risultato.

Prima trappola, l'SNI. Senza di esso, entrambe le porte restituiscono la sentinella di Google, CN=invalid2.invalid con OU=No SNI provided - please fix your client., numero B3E9BADC: uno scanner senza SNI registra un valore perfettamente stabile e perfettamente falso, sempre senza errori.

La porta in sé non è però la causa dello scarto tra 389 e 636. Il listener della 389 detiene entrambi i certificati e sceglie in base agli algoritmi di firma che il client annuncia:

openssl s_client -starttls ldap -connect ldap.google.com:389 -servername ldap.google.com \
  -sigalgs 'RSA-PSS+SHA256:rsa_pkcs1_sha256' </dev/null 2>/dev/null | openssl x509 -noout -serial

serial=E97CCECBFFF70F940963C3B2C1F06634

La 389 restituisce quindi su richiesta il certificato che si credeva proprio della 636. L'inverso fallisce: ECDSA+SHA256 forzato sulla 636 provoca un tls alert handshake failure (alert 40), senza alcun certificato. La 636 ha solo l'RSA, ed è ciò che salva l'indicizzazione per coppia (host, porta). Ma la configurazione TLS dello scanner è una variabile d'ingresso al pari della porta: due scanner con algoritmi di firma diversi inventariano due numeri di serie diversi sulla stessa coppia, senza sollevare il minimo errore. Congela e documenta la configurazione TLS dello scanner, altrimenti l'inventario non è riproducibile da un'esecuzione all'altra.

Altrove il comportamento si inverte: da Gmail, le porte 465 e 587 servono lo stesso certificato, 6D09D839.... Nulla di tutto ciò si indovina, e un inventario indicizzato sul nome host conta male in entrambe le direzioni: fonde certificati distinti o duplica lo stesso.

La griglia di audit da scaricare a fine articolo riprende queste colonne: una riga per coppia (host, porta), la modalità TLS, lo stato dell'ultima scansione con i suoi tre valori possibili, il metodo di deposito, quello di ricarica, il proprietario con nome e cognome e la classe di automazione. Tre righe di esempio mostrano la compilazione attesa, il resto è vuoto.

Delegare _acme-challenge senza dare le chiavi della zona

Delegare _acme-challenge tramite CNAME dà al client ACME un diritto di scrittura su una zona di validazione dedicata, e nient'altro. La tua zona di produzione, invece, non si muove: stessi record, stessa API chiusa.

Cos'è la delega CNAME, e cosa non è

La RFC 8555 non menziona il CNAME. La parola non compare da nessuna parte nel suo testo, verifica fatta. La delega non è quindi una raccomandazione dello standard ACME: è documentata e supportata da Let's Encrypt, la cui validazione DNS-01 segue le regole DNS ordinarie e accetta che un CNAME o una delega NS rimandi la risposta alla challenge verso un'altra zona. Sul piano normativo, i Baseline Requirements citano esplicitamente il record CNAME tra i supporti validi del metodo di validazione «DNS Change», alla sezione 3.2.2.4.7.

La distinzione sta in una riga: supportata dall'ecosistema, assente dallo standard.

Il beneficio, invece, è netto. Il client ACME riceve credenziali che scrivono solo in una zona di validazione, spesso ospitata altrove. La compromissione del server che rinnova non dà quindi alcun potere sui tuoi record MX, A o TXT di produzione. Passando in rassegna 32 domini pubblici, abbiamo trovato diverse deleghe reali di questo tipo: fastmail.com rimanda a fastmail.com.acme-challenge.fmhosted.com, github.com a github.com.acme.github.net, reddit.com a una destinazione dcv.cloudflare.com, eff.org e digitalocean.com a fastly-validations.com.

Verificare una delega: tre passaggi, mai uno solo

Una sola query non prova nulla. La verifica completa ne richiede tre, e la terza è quella che trasforma un dubbio in prova.

Passaggio 1, il CNAME esiste:

dig +noall +answer _acme-challenge.fastmail.com CNAME

_acme-challenge.fastmail.com. 3600 IN CNAME fastmail.com.acme-challenge.fmhosted.com.

È tutto quello che dice questo comando: un CNAME è scritto. Non prova che la delega funzioni.

Passaggio 2, seguire la catena fino al TXT e leggere lo stato:

dig +noall +answer +comments _acme-challenge.fastmail.com TXT

Tre casi reali, ed è qui che la maggior parte degli articoli sbaglia:

CASO A - fastmail (CNAME presente, destinazione senza TXT attivo)
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59352
_acme-challenge.fastmail.com. 3600 IN CNAME fastmail.com.acme-challenge.fmhosted.com.

CASO B - reddit (CNAME presente, destinazione esistente)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8461
_acme-challenge.reddit.com. 292 IN CNAME reddit.com.7ee8918f112aca0f.dcv.cloudflare.com.

CASO C - captaindns.com (nessuna delega)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27534
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Bisogna incrociare due segnali, mai uno solo. Un CNAME nella sezione ANSWER con un NXDOMAIN significa che la delega è scritta ma che la destinazione non esiste in quel momento, perché il TXT viene creato solo al momento della challenge. È lo stato normale tra due rinnovi: sulle sette deleghe pubbliche che abbiamo interrogato, sei erano in questa condizione. Il vero fallimento è un NOERROR con ANSWER: 0, ossia nessuna delega. Un monitoraggio che allerta sull'NXDOMAIN di _acme-challenge produrrà rumore permanente, e sbaglierà sei volte su sette.

Passaggio 3, verificare a livello autoritativo e confermare che la zona di destinazione è viva:

ns=$(dig +short NS fastmail.com | head -1)
dig +noall +answer +comments @"$ns" _acme-challenge.fastmail.com CNAME
dig +noall +answer +comments acme.github.net SOA

Il SOA di acme.github.net risponde NOERROR mentre la query TXT su _acme-challenge.github.com restituiva NXDOMAIN: la delega è sana, manca solo la risposta alla challenge perché nessun rinnovo è in corso. Un SOA in NXDOMAIN o in SERVFAIL sulla zona di destinazione, al contrario, segnala una delega rotta per davvero, tipicamente un account di validazione eliminato o un dominio scaduto.

Il nome inizia con un underscore, che alcune interfacce di amministrazione mangiano o raddoppiano come prefisso: verifica l'FQDN restituito nella risposta DNS, non ciò che mostra il pannello; una query CNAME sullo strumento DNS Lookup lo mostra senza aprire un terminale. Un CNAME su _acme-challenge è incompatibile con qualsiasi altro record con lo stesso nome, per cui un vecchio TXT di validazione rimasto lì rende la zona invalida. I TTL osservati vanno da 3600 a 120 secondi a seconda dei domini: dopo una correzione, un resolver può servire la vecchia risposta, NXDOMAIN compreso, per tutta quella durata, ed è la causa numero uno dei fallimenti di validazione subito dopo una modifica. Il head -1 interroga un solo server autoritativo. Infine, interrogare la zona di destinazione non prova che il client vi abbia i diritti di scrittura: solo un'emissione reale lo prova.

Il limite di un solo delegato per dominio, e il draft che lo rimuove

Il DNS consente un solo CNAME per nome. _acme-challenge.captaindns.com può quindi essere delegato a un solo client alla volta. Multi-CDN, multi-regione, migrazione senza interruzioni, certificato di riserva emesso da una seconda autorità: questi quattro bisogni sbattono tutti contro lo stesso muro, e lato DNS non esiste alcuna soluzione pulita.

Un draft in corso all'IETF affronta il problema. Il draft-ietf-acme-dns-account-label-03, Active Internet-Draft del gruppo di lavoro ACME, revisione 03 del 15 maggio 2026, in working group last call al momento della nostra verifica, definisce una challenge chiamata dns-account-01. Il principio: anteporre al nome di validazione un digest dell'URL dell'account ACME, secondo la costruzione "_" || base32(SHA-256(ACCOUNT_URL)[0:10]) || "._acme-challenge". Ogni account ottiene così il proprio nome di validazione, e più client possono validare in parallelo sullo stesso dominio.

È un draft, non uno standard. Non ha un numero di RFC, il suo contenuto può cambiare alla prossima revisione, e non annunciamo alcuna disponibilità presso un'autorità di certificazione. Da seguire se la tua architettura è multi-provider, da non mettere in un piano di deployment.

Il rinnovo di un certificato SSL non si ferma all'emissione: la ricarica è il vero anello debole

certbot renew scrive il nuovo certificato sul disco. Non ricarica né nginx, né postfix, né haproxy. Tra il momento in cui l'emissione riesce e quello in cui il servizio presenta il nuovo certificato c'è una ricarica, ed è lì che la catena si rompe più spesso, senza che nessun log si accenda. La contromisura lato client si chiama deploy hook, e la guida alla gestione del ciclo di vita dei certificati le dedica la sua fase 3; il controllo che segue verifica, dall'esterno, che abbia davvero funzionato.

Il controllo post-rinnovo, e i suoi cinque falsi positivi

L'unico controllo che conta confronta il numero di serie letto sul disco con quello realmente servito sulla rete:

HOST=api.captaindns.com
FILE=/etc/letsencrypt/live/$HOST/fullchain.pem

disk=$(openssl x509 -in "$FILE" -noout -serial | cut -d= -f2)
served=$(openssl s_client -connect "$HOST:443" -servername "$HOST" </dev/null 2>/dev/null \
         | openssl x509 -noout -serial | cut -d= -f2)

echo "disco  =$disk"
echo "servito=$served"
[ "$disk" = "$served" ] \
  && echo "OK: il certificato servito è quello del disco" \
  || echo "ALLARME: il servizio serve un VECCHIO certificato -> reload necessario"

Entrambi i rami sono stati effettivamente eseguiti, con due numeri di serie distinti:

CASO 1 - concordanza
disco  =05DFD8366DC6A73780F3707BC7E13F91E0EC
servito=05DFD8366DC6A73780F3707BC7E13F91E0EC
OK: il certificato servito è quello del disco

CASO 2 - divergenza
disco  =05DFD8366DC6A73780F3707BC7E13F91E0EC
servito=05B499411D7820A6C0EC7A0626E1BA25CF67
ALLARME: il servizio serve un VECCHIO certificato -> reload necessario

Questo controllo ha le sue trappole, e la prima è banale. Il cut -d= -f2 non è decorativo: openssl stampa serial=05DF... e il confronto fallisce senza di esso. Confronta il numero di serie, mai la data di scadenza: due certificati rinnovati lo stesso giorno possono condividere notAfter. Il file fullchain.pem contiene più certificati e openssl x509 -in legge solo il primo, per cui un file ordinato al contrario fa confrontare l'intermedio e fallire il test in permanenza. Dietro un load balancer che termina il TLS, il certificato posato sul disco dell'origine non ha alcun rapporto con ciò che viene servito al pubblico: il controllo diventa un falso positivo permanente, e va puntato dall'esterno del load balancer. Infine, per identificare il file anziché l'emissione, sostituisci -serial con -fingerprint -sha256.

Questo controllo non ha nulla di specifico alla 443. L'abbiamo rigiocato fuori dal web: in TLS implicito sulla porta 465, poi in STARTTLS sulla porta 587, con lo stesso numero di serie 6D09D839... da entrambi i lati. Un parco di posta si controlla esattamente allo stesso modo, a parte l'opzione di connessione.

L'impronta SPKI SHA-256 offre un controllo complementare, a monte. È esposta sia dal nostro SSL Certificate Checker sia dal CSR Parser, quanto basta per provare che una data CSR ha davvero prodotto il certificato servito. L'accostamento è manuale: nulla lo fa automaticamente al posto tuo.

Tutti i tuoi frontend servono lo stesso certificato?

Un ciclo sugli indirizzi IP del servizio risponde alla domanda in pochi secondi:

HOST=debian.org
for ip in $(dig +short A "$HOST" | grep -E '^[0-9]'); do
  printf '%-16s ' "$ip"
  openssl s_client -connect "$ip:443" -servername "$HOST" </dev/null 2>/dev/null \
    | openssl x509 -noout -serial | cut -d= -f2
done

Su debian.org, i quattro indirizzi restituiti hanno reso tutti lo stesso numero di serie, 057EB3AB.... Parco omogeneo da questo lato. Il cuore del trucco sta nel -servername posto mentre ci si connette a un IP: senza di esso si ottiene il certificato predefinito del frontend, non quello del vhost mirato. Il grep -E '^[0-9]' filtra le righe di CNAME che dig +short inserisce, comportamento osservato su www.google.com a causa di una riscrittura del resolver locale.

Il ciclo copre solo l'IPv4: aggiungi un passaggio su dig +short AAAA con -connect "[$ip]:443". L'altro limite è più insidioso. Dietro un anycast (uno stesso indirizzo annunciato da più punti del globo), quei quattro indirizzi appartengono allo stesso punto di presenza visto dalla tua postazione: lo provi quattro volte, non gli altri N distribuiti nel mondo.

Diagnosticare una porta identificata male in una riga di errore

Inutile indovinare la modalità di una porta: openssl la dice nel suo messaggio di errore. Un wrong version number significa che manca -starttls: il server si aspetta un dialogo in chiaro prima della negoziazione. Al contrario, un Didn't find STARTTLS in server response, trying anyway... seguito da un unexpected eof while reading significa che il -starttls è di troppo, su una porta già cifrata: openssl tenta comunque, aspetta un banner in chiaro da un server che si aspetta solo TLS, e la connessione muore su un EOF.

Il comando equivalente su un MX in porta 25 si scrive così:

openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 \
  -servername gmail-smtp-in.l.google.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -serial

Non validato dalla nostra postazione, porta 25 in uscita filtrata; sintassi validata in modo identico sulla 587. Non pubblichiamo quindi alcun output per questo comando. Tre trappole vale comunque la pena segnalarle: il 2>/dev/null inghiotte l'errore reale e ti lascia con un Could not find certificate from <stdin> qualunque sia il problema, il </dev/null evita che la sessione resti aperta, e il -servername deve portare il nome dell'MX, non quello del dominio di posta.

DANE e TLSA: l'unico caso in cui l'ordine delle operazioni è normativo

La ricarica ha un ultimo piano, riservato agli MX che pubblicano record TLSA. Lì l'ordine delle operazioni smette di essere una buona pratica per diventare un obbligo. La RFC 7671, sezione 8.1, descrive la rotazione in quattro tempi: pubblicare il record TLSA del futuro certificato accanto a quello del certificato corrente, attendere almeno due TTL il tempo che le cache si svuotino, distribuire allora il nuovo certificato e verificare che funzioni, quindi rimuovere il record diventato obsoleto. Due TTL, non 48 ore: la RFC ragiona in TTL, e i tuoi TTL non sono i nostri.

Per SMTP, la RFC 7672 ne fa un obbligo formale. In caso di disallineamento, la consegna tramite quel server è vietata, e il mittente passa all'MX successivo o rimanda la consegna.

La modalità di guasto è asimmetrica, ed è ciò che la rende temibile. Lato operatore in errore, nessun alert: la connessione viene abortita dal client, i mittenti che non validano DANE continuano a consegnare, il monitoraggio resta verde. La RFC 7672 usa la parola «unwittingly» per descrivere quel dominio partner che si ritrova mal configurato a sua insaputa. Lato mittente validante non è silenzioso, ma differito: i messaggi si accumulano in coda, con avvisi di ritardo e poi eventuali bounce alla scadenza. Il destinatario finale, invece, non riceve né il messaggio né la minima notifica.

Resta una condizione che la sezione 8.1 pone senza sottolinearla: l'usage, il selector e il matching type devono restare invariati. Se modifichi uno di questi tre parametri, si applica la sezione 8.3, e la regola si inverte.

I casi ribelli ad ACME: ciò che non si lascia automatizzare

Una parte del parco resiste, e non per ragioni di protocollo. ACME sa emettere per quasi tutto. Ciò che si inceppa è l'installazione, la ricarica, o il livello di validazione richiesto.

La PKI interna e i certificati di due anni

Le autorità interne sfuggono al calendario del CA/Browser Forum, quindi nulla le spinge ad accorciare né ad automatizzare. L'istanza dimostrativa pubblica di FreeIPA lo mostra bene: alla rilevazione del 21 luglio 2026, ipa.demo1.freeipa.org serviva un certificato valido dal 23 aprile 2025 al 24 aprile 2027, cioè due anni, su una catena firmata da una root privata.

Visto da una postazione esterna, openssl restituisce verify error:num=19 self-signed certificate in certificate chain. Questo codice viene spesso confuso con un altro: verify error:num=20 unable to get local issuer certificate. Non descrivono la stessa situazione. Il 19 significa che il server invia effettivamente la sua root privata nella catena, ma che è assente dal tuo store locale. Il 20 significa che l'intermedio non viene inviato affatto e che openssl non può risalire la catena. In entrambi i casi la diagnosi è la stessa: problema di trust store, non problema di certificato. Anche la correzione: -CAfile internal-ca.pem.

Esistono gateway per riportare questi parchi verso ACME. Nessuno si distribuisce senza contropartita, ed è meglio conoscerla prima.

• acme2certifier, con licenza GPLv3, mette una facciata ACME davanti a Microsoft ADCS tramite MS-WCCE o i Certificate Enrollment Web Services. La revoca non è supportata e la catena dell'autorità va caricata a mano. È un progetto della community portato avanti da un solo manutentore, attivo: versione 0.44 il 18 luglio 2026.
• step-ca è un single point of failure nella sua configurazione predefinita, a causa del suo database embedded Badger che non gestisce la concorrenza. La documentazione descrive un deployment multi-istanza, al prezzo di un database MySQL o PostgreSQL esterno e della gestione remota dei provisioner.
• HashiCorp Vault espone un server ACME dalla versione 1.14.0, con una durata di vita limitata a 90 giorni. È un server, non un client, e la sfumatura cambia tutto in un'architettura.
• EJBCA Community Edition: Keyfactor lo scrive di suo pugno nel README del repository ufficiale, «EJBCA Community Edition is not intended for production use.»

I certificati che ACME non può rilasciare

Il livello di Extended Validation non si ottiene tramite ACME. Presuppone una verifica di identità giuridica (categoria di attività, giurisdizione di registrazione, numero di iscrizione al registro delle imprese) che nessuna challenge automatizzata produce.

Il caso si incontra in produzione. Alla stessa rilevazione, sulla porta 465, posteo.de serviva un certificato Extended Validation valido dal 18 febbraio 2026 al 24 febbraio 2027, cioè 371 giorni. Eppure nessuna violazione del tetto dei 200 giorni. Il certificato è stato emesso prima del 15 marzo 2026, e la regola non è retroattiva. Non ne traiamo alcuna conclusione sulle pratiche di rinnovo di questo operatore.

Il campo si restringe ancora. I certificati di marchio VMC e CMC, usati da BIMI, si decodificano con il nostro analizzatore dedicato ma non sono certificati TLS di server. I certificati client, in particolare quelli che portano un'autenticazione mutua, seguono a loro volta una catena di emissione e una distribuzione che non hanno nulla a che vedere con ACME.

Gli endpoint che nessuno script ricarica

Ecco il vero tetto dell'automazione, e l'unico numero che conta per decidere un acquisto. Passa in rassegna il tuo parco e conta ciò che segue.

Gli apparati di rete amministrabili solo tramite interfaccia web. I load balancer hardware, il cui aggiornamento del certificato passa da un form. Le stampanti, gli apparati industriali, le telecamere e tutto ciò che ospita un server HTTPS dimenticato dall'installazione. I keystore Java protetti da una password interattiva, che bloccano di netto qualsiasi esecuzione non presidiata. Gli store Windows, dove installare un certificato non basta poiché un binding IIS può continuare a puntare a un'altra impronta. Le terminazioni TLS gestite presso un provider che non espone alcuna API.

Il punto in comune non è l'emissione: ACME sa emettere per tutti questi nomi. Sono l'installazione e la ricarica a restare manuali. Uno script può ottenere il certificato in pochi secondi, poi aspettare che una persona si colleghi a un'interfaccia per posarlo. A 200 giorni di validità, quella persona interviene due volte l'anno e nessuno se ne lamenta. A 47 giorni interviene otto volte l'anno e per endpoint come minimo assoluto, rinnovando alla scadenza, e undici o dodici rinnovando ai due terzi come raccomandato. Il costo diventa una voce di budget.

Misuralo adesso, mentre la frequenza è ancora bassa: numero di endpoint coinvolti, minuti realmente spesi per rotazione, proprietario con nome e cognome. Queste tre colonne valgono più di qualsiasi comparativo di strumenti.

Cadenza, profili brevi e ciò che davvero limita un ciclo di rinnovo

Un ciclo di rinnovo non è limitato dalla dimensione del parco. È limitato dalla cadenza con cui ogni nome riemette, e da due o tre rate limit tutt'altro che intuitivi.

Quando rinnovare: la regola dei due terzi ha un'eccezione

La regola generale è semplice: rinnovare quando resta un terzo della durata di vita totale. Cioè 30 giorni prima della scadenza per un certificato di 90 giorni. Ma la documentazione di Let's Encrypt prevede un'eccezione esplicita per i certificati validi meno di dieci giorni: per quelli, il rinnovo è raccomandato a metà vita.

Il profilo shortlived rientra esattamente nell'eccezione. Vale 160 ore, cioè 6,67 giorni. La sua metà vita è quindi a 80 ore, il che dà 2,1 emissioni a settimana per nome.

Questo 2,1 è un modello, non un valore pubblicato da Let's Encrypt. Le sue cinque ipotesi, in chiaro. La validità di 160 ore è documentata. La settimana ridotta a 168 ore fisse è un'approssimazione: il meccanismo reale è un token bucket a ricarica continua. Il rinnovo a una frazione fissa e deterministica, senza jitter né nuovi tentativi, è un'ipotesi di modellazione. Un certificato uguale un nome, mentre shortlived accetta fino a 25 nomi: raggruppare divide il numero di certificati di altrettanto. E il calcolo presuppone zero fallimenti.

Riserva più importante: con ARI, che è la modalità nominale, la cadenza non segue una frazione fissa ma la finestra suggerita dal server, di cui non sono pubblicate né la posizione né l'ampiezza. Qualsiasi cadenza espressa in frazione di durata di vita descrive quindi una rete di sicurezza, non il regime normale.

Quanto alla «trentina di nomi per dominio in profilo breve» che circola, divide una quota che i rinnovi non consumano per una cadenza che non si applica a questo profilo: non la riprendiamo.

Che cosa Let's Encrypt chiama rinnovo

Due meccanismi, due regimi di esenzione. Confonderli è l'errore che costa di più in esercizio.

Tramite ARI, il comando newOrder designa esplicitamente il certificato che sostituisce. Tre condizioni, in realtà: questa designazione, almeno un identificatore in comune con il certificato uscente, e un uscente che non sia già stato sostituito una prima volta. L'esenzione è allora totale. Tutti i limiti saltano, senza eccezioni, e il perimetro dei SAN può perfino cambiare, poiché l'identità del certificato uscente è portata dal campo dedicato.

Tramite rilevamento su insieme esatto, il regime è più stretto. L'insieme di identificatori deve essere rigorosamente identico, maiuscole e ordine essendo ininfluenti (sfumatura che molti articoli invertono). L'esenzione copre allora soltanto New Orders per Account e New Certificates per Registered Domain.

Il corollario merita di essere appeso al muro: ingrandire un certificato SAN per aggiungervi un sottodominio consuma la quota dei 50 per dominio registrato, mentre il rinnovo identico non ne consuma nessuna. Scrivere «50 certificati a settimana per dominio» senza questa precisazione equivale a descrivere un tetto di parco che non esiste. Questo limite misura un flusso in ingresso di nuovi nomi.

I limiti che mordono, in ordine di pericolosità

Cinque rate limit vanno conosciuti, e non si equivalgono. Eccoli dal più pericoloso al meno fastidioso.

Il primo è l'unico che un ciclo legittimo può esaurire da solo: 5 fallimenti di autorizzazione per identificatore, per account e per ora, ricarica di un fallimento ogni 12 minuti, nessun innalzamento possibile, e soprattutto un'applicazione ai rinnovi. Il secondo conta i fallimenti consecutivi e mette l'identificatore in pausa dopo 1152 fallimenti di fila. È un contatore di serie, non una portata, e si ricarica di un token per identificatore e per giorno: una giornata a cinque fallimenti ne consuma solo quattro netti, e la pausa arriva soltanto dopo 288 giorni; a 120 fallimenti al giorno cade dopo 10 giorni, e a uno solo al giorno, mai. Questi valori non escono da un calcolo fatto in casa, la documentazione Let's Encrypt pubblica la tabella. Non fondere i due limiti.

Viene poi il vero tetto di un ciclo senza ARI: 5 certificati per insieme esatto di identificatori ogni 7 giorni, ricarica di un certificato ogni 34 ore, nessun innalzamento. Una cadenza di 2,1 passa comodamente, e il margine assorbe i nuovi tentativi. Più in basso nella classifica, 10 account per indirizzo IP ogni 3 ore morde solo se ogni nodo crea il proprio account invece di condividerne uno. L'ultimo non è nemmeno una quota, ma un vincolo di profilo: shortlived si ferma a 25 nomi per certificato, contro 100 in classic. Passare al profilo breve impone quindi di ritagliare di nuovo i grossi certificati SAN, e questi ritagli sono emissioni nuove, non rinnovi.

I rate limit di Let's Encrypt che riguardano un ciclo di rinnovo

Valori documentati sulla pagina ufficiale dei rate limit, consultata il 21 luglio 2026. Queste esenzioni e questi tetti sono propri di Let's Encrypt e non si generalizzano alle altre autorità di certificazione.

5

Fallimenti di autorizzazione per identificatore, per account e per ora

Ricarica di un fallimento ogni 12 minuti, nessun innalzamento possibile, applicabile ai rinnovi.

5

Certificati per insieme esatto di identificatori ogni 7 giorni

Ricarica di un certificato ogni 34 ore, nessun innalzamento possibile.

50

Nuovi certificati per dominio registrato ogni 7 giorni

Flusso in ingresso di nuovi nomi, ricarica di un certificato ogni 202 minuti. I rinnovi ne sono esentati.

1152

Fallimenti consecutivi prima della messa in pausa dell'identificatore

Contatore di serie azzerato non appena una validazione riesce, uscita tramite il portale self-service.

La guida all'integrazione dell'ente aggiunge due consigli operativi: oltre i 10 000 nomi, rinnovare a piccoli lotti anziché a grossi blocchi, e distribuire una volta per tutte le date di rinnovo. Il modulo di innalzamento della quota riguarda solo due limiti, richiede qualche settimana di lavorazione e non azzera mai un contatore: strumento di pianificazione, non ricorso d'emergenza.

Tutto quanto precede descrive la policy di Let's Encrypt, e nient'altro. In AWS Certificate Manager, la cifra strutturante non è un numero di certificati ma una portata, FinalizeOrder limitato a una richiesta al secondo, e queste quote sono documentate nella guida utente.

La vera modalità di guasto: due scenari, e nessuno è una quota

Gli incidenti di rinnovo che vediamo non assomigliano a una quota di emissione superata. Assomigliano a questi due scenari, che condividono una caratteristica sgradevole: peggiorano da soli.

Scenario 1, il ciclo di fallimento. Una credenziale DNS scade, una delega si rompe, la porta 80 si chiude dietro un cambio di regola di rete. Il client ACME riprova, spesso in modo aggressivo perché è l'impostazione predefinita di molte configurazioni. Al sesto fallimento nell'ora sullo stesso identificatore, ogni ordine che porta quel nome viene rifiutato, e la ricarica scende a un fallimento ogni 12 minuti. Un incidente riparabile in dieci minuti si trasforma in un guasto di diverse ore, non a causa del problema originario, ma a causa del comportamento del client di fronte al problema. E nel frattempo il contatore dei fallimenti consecutivi sale verso i 1152 del secondo limite. La contromisura sta in due impostazioni: un backoff esponenziale lato client, e un alert sul fallimento di validazione anziché sul solo avvicinarsi della scadenza.

Scenario 2, il rinnovo che smette di esserlo. Senza ARI, aggiungere o togliere un solo nome da un certificato SAN gli fa perdere lo status di rinnovo e ribalta l'ordine sulla quota dei nuovi nomi. Ora, molti parchi generano i loro insiemi di SAN da un inventario dinamico: ingress controller Kubernetes, ambienti effimeri, piattaforme di preview. Nessun ordine è più un rinnovo, e un parco per altro stabile consuma il flusso riservato ai nuovi nomi.

Ciò che rende reale questo secondo scenario è lo stato dei client al 21 luglio 2026. Certbot legge ARI ma non invia il campo replaces: la sua implementazione resta in sola lettura, quindi tutti i suoi ordini si basano sul rilevamento per insieme esatto. lego invia replaces dalla v4.16.0 ma, dalla v5.1.0, ignora ARI se i SAN sono cambiati. cert-manager sa inviarlo, dietro il feature gate ACMEUseARI, classificato Alpha e disattivato di default, disponibile dalla v1.21.0 pubblicata l'8 luglio 2026. acme.sh lo invia dalla versione 3.1.4, pubblicata il 17 luglio 2026, cioè quattro giorni prima della nostra verifica su questo punto. La protezione esiste nello standard da giugno 2025. È operativa quasi da nessuna parte.

Monitoraggio della scadenza dei certificati SSL: due cose da monitorare, non una

Il monitoraggio della scadenza e quello del fallimento di rinnovo sono due sistemi distinti. Il primo vede la conseguenza, con settimane di ritardo. Il secondo vede la causa, il giorno stesso. Un parco attrezzato bene ha entrambi, e non dipendono dallo stesso componente.

Soglie che non sopravvivono ai certificati brevi

Una soglia di alert fissata a 30 giorni diventa assurda su un certificato di 47 giorni. Scatta già al 17esimo giorno di vita del certificato, cioè per più della metà della sua esistenza. L'alert è permanente, quindi invisibile, quindi inutile. La soglia deve diventare relativa alla durata di vita: una frazione, non una costante.

Tanto vale applicare questa esigenza ai nostri stessi strumenti. L'SSL Certificate Checker di CaptainDNS usa una soglia «in scadenza» fissata a 30 giorni, e i livelli di alert della nota di postura sono G-30, G-14, G-7, G-3 e G-1. Una soglia relativa del tipo max(15, durata di vita / 3) è prevista dalla specifica interna, ma non è implementata. Su un parco in profilo breve, questi valori vanno ricalcolati da te.

Cosa deve far scattare un alert oltre alla scadenza

Oltre alla data di scadenza, sei segnali meritano un alert. L'ultimo dell'elenco è il più utile di tutti.

• Un cambio di numero di serie segnala un rinnovo effettivo, quindi una buona notizia che va comunque vista passare.
• Un cambio di emittente può tradire un passaggio di autorità non previsto.
• Una catena diventata incompleta rompe la validazione solo presso una parte dei client, il che la rende difficile da riprodurre.
• Un nome host che non corrisponde più arriva dopo una migrazione.
• Un protocollo o una chiave diventati deboli indicano una configurazione che è regredita.
• E soprattutto, il fallimento di validazione ACME: l'unico segnale che arriva abbastanza presto da evitare il guasto.

Al contrario, due riflessi producono solo rumore. Non allertare mai su un NXDOMAIN di _acme-challenge, per la ragione esposta sopra. E non allertare su un semplice cambio di impronta senza cambio di stato visibile, pena raccogliere falsi positivi a ogni switch di frontend.

I nostri limiti, detti francamente, perché cambiano il modo in cui vanno letti i paragrafi precedenti. La nota di postura è un opt-in a pagamento per monitor. La sua cadenza predefinita è di 86 400 secondi, cioè un passaggio al giorno: parlare di «monitoraggio continuo» sarebbe falso. Non c'è alcuna scoperta del parco, nessuna enumerazione tramite i log di trasparenza: monitori ciò che dichiari, un URL alla volta. E non c'è alcun STARTTLS, quindi nulla sui tuoi server di posta.

A partire da quando conviene pagare uno strumento?

La soglia d'acquisto non si conta in certificati. Si conta in endpoint che nessuno script sa ricaricare. Un parco di 800 certificati interamente pilotati da un ingress controller non giustifica alcuna spesa; un parco di 60 certificati di cui 25 vivono su apparati con interfaccia web la giustifica subito.

Classifica il tuo parco in tre colonne, poi conta la terza.

Classe	Cosa fa lo script	Cosa resta umano
Automatizzabile end-to-end	Emissione, installazione, ricarica, verifica del numero di serie servito	Nulla in regime nominale
Semi-automatizzabile	Emissione e deposito del file	Installazione o ricarica manuale, spesso da una console
Non automatizzabile	Solo emissione	Accesso a un'interfaccia web, import del file, riavvio

Il punto di svolta si legge sulla terza riga, moltiplicata per la frequenza futura. Un endpoint non automatizzabile costa, in regime 47 giorni, otto interventi l'anno come minimo assoluto, quello di un rinnovo alla scadenza, e undici o dodici rinnovando ai due terzi come raccomandato; la guida al ciclo di vita ne modella poco meno di otto con un'altra ipotesi di calendario, senza che l'ordine di grandezza cambi. Contro due oggi. Fai il prodotto con i tuoi minuti misurati, non stimati, e confrontalo con il prezzo di una licenza: il calcolo non richiede né benchmark né gara d'appalto.

Il modello di soglia fornito a fine articolo rende queste ipotesi modificabili una per una: numero di endpoint non ricaricabili, cadenza di rotazione per fase di validità, minuti per rotazione, costo orario caricato e prezzo di riferimento. Ogni valore precompilato porta il suo stato, documentato, derivato o rilevato a una data, così che sostituire le nostre ipotesi con le tue richiede un minuto.

Appunto, i prezzi. Su AWS Marketplace, rilevazione del 21 luglio 2026, la scheda AppViewX AVX ONE CLM mostra due livelli pubblici su contratto di un mese: 2100 $ al mese per 100 certificati server e 4200 $ al mese per 250 certificati server. Lo stesso vendor pubblica 5000 $ e 9100 $ al mese sulla sua scheda PKIaaS, il che impedisce di presentare i 2100 $ come «il» prezzo pubblico del vendor. La scheda Venafi Certificate Management Service non riporta alcun prezzo e rimanda a un'offerta privata su preventivo. La scheda DigiCert mostra un importo di 5000 $ per un contratto di dodici mesi, precisando però che è riservata agli acquisti su offerta privata. Questa rilevazione riguarda le schede consultate quel giorno, su un solo marketplace, e la nozione di prezzo pubblicamente sottoscrivibile. Non dice nulla delle tariffe negoziate, né dei vendor assenti da questa rilevazione.

Una parola sul mercato, formulata come constatazione di assenza. Nessun Magic Quadrant dedicato alla gestione del ciclo di vita dei certificati è indicizzato su gartner.com: la società tratta il tema con un «Buyers' Guide for PKI and Certificate Life Cycle Management» pubblicato il 29 maggio 2025 e con uno spazio di recensioni utenti Peer Insights. Quanto alle cifre che circolano negli argomentari di vendita, sono attribuibili e nulla di più: in un comunicato del 2 luglio 2025, DigiCert indica che il 45 % dei rispondenti alla sua indagine «Trust Pulse» dichiara di aver subito un'interruzione di servizio legata a un incidente di certificato, e che il 31 % riporta perdite comprese tra 50.000 e 250.000 dollari. Il comunicato non precisa né il numero di rispondenti, né il loro profilo, né i paesi coperti, né il periodo di raccolta, e non abbiamo trovato alcun report che dettagli questa metodologia a quella data. Sono dichiarazioni di rispondenti a un'indagine commissionata da un attore della categoria, non una misura.

Tieni a mente il gesto, non le cifre: conta la terza colonna, moltiplica per i tuoi minuti, confronta.

🎯 Piano d'azione: la sequenza da svolgere

Otto azioni, in quest'ordine. Le prime tre si fanno una volta sola; le successive diventano riflessi operativi.

1. Inventariare per coppia (host, porta), incrociando i log di trasparenza, il disco e gli store, poi la scansione di rete. Lancia questa scansione da una rete che non filtra le porte in uscita, altrimenti i tuoi server di posta non compariranno mai.
2. Trattare «host non raggiunto» come un fallimento dell'inventario, con una riga esplicita nel report. Un irraggiungibile silenzioso contato come un successo è ciò che rende falsa una dashboard.
3. Delegare _acme-challenge tramite CNAME, poi verificare la delega in tre passaggi: il CNAME esiste, la catena si risolve, la zona di destinazione risponde in SOA. E non allertare sugli NXDOMAIN fuori dal periodo di rinnovo.
4. Verificare dopo ogni rinnovo che il numero di serie servito sia quello del disco, anche fuori dalla 443. È il controllo che intercetta la ricarica dimenticata, e costa due righe di script.
5. Mettere un backoff esponenziale nel client e allertare sul fallimento di validazione. Senza questo, un incidente di dieci minuti si trasforma in un blocco di un'ora.
6. Verificare che il tuo client invii replaces, oppure accettare di dipendere dal rilevamento per insieme esatto, il che equivale a congelare i tuoi SAN.
7. Passare le soglie di alert da un valore fisso a una frazione della durata di vita. Trenta giorni non vogliono dire nulla su un certificato di 47 giorni.
8. Contare i tuoi endpoint non ricaricabili prima di confrontare degli strumenti. È questo numero a decidere l'acquisto; il numero di certificati, no.

Otto azioni, due file da scaricare, e un solo numero da produrre: il numero di endpoint che nessuno sa ricaricare. È lui a decidere il seguito, non la dimensione del parco.

FAQ

È possibile rinnovare automaticamente un certificato SSL?

Sì, ed è la modalità nominale con ACME da anni. La vera domanda riguarda la catena completa: emissione, installazione, ricarica del servizio e verifica. L'estensione ARI permette in più di seguire la finestra suggerita dall'autorità, ma il suo supporto lato client resta disomogeneo al 21 luglio 2026. Certbot la legge senza inviare il campo replaces, cert-manager la tiene dietro un feature gate disattivato di default, acme.sh l'ha cablata nella versione 3.1.4 il 17 luglio 2026.

Come automatizzare il rinnovo dei certificati SSL?

Bastano tre mattoni. Un client ACME schedulato, che ottiene il certificato. Una delega _acme-challenge tramite CNAME verso una zona di validazione dedicata, il che evita di affidare le chiavi della tua zona di produzione al server che rinnova. E un controllo che confronta il numero di serie letto sul disco con quello realmente servito sulla porta interessata. Il terzo mattone è quello che si dimentica, ed è quello che rileva la ricarica mancante.

Come rinnovare un certificato SSL?

Un rinnovo non è un prolungamento: è una riemissione completa, con una nuova validazione del controllo del dominio se la finestra di riutilizzo è scaduta. Da Let's Encrypt, un ordine viene riconosciuto come rinnovo in due modi: designa il certificato che sostituisce tramite ARI, oppure porta esattamente lo stesso insieme di identificatori del certificato uscente. In entrambi i casi sfugge ai limiti di emissione per i nuovi nomi.

Come verificare che un rinnovo abbia davvero avuto effetto?

Lascia che il client ACME faccia l'emissione, poi verifica il risultato dalla rete anziché dai log del client. Il comando utile confronta openssl x509 -in fullchain.pem -noout -serial con il numero di serie restituito da openssl s_client sul servizio. Se i due differiscono, il certificato è rinnovato sul disco ma il servizio serve ancora il vecchio: manca una ricarica.

Cosa fare se il mio certificato SSL scade?

Su un servizio web la scadenza si vede subito: i browser bloccano. Su un server di posta protetto da DANE è più subdolo. La RFC 7672 vieta la consegna tramite un server la cui autenticazione fallisce, e il mittente passa all'MX successivo o rimanda la consegna: dalla tua parte, nessun alert. Comincia quindi la diagnosi con una lettura del certificato realmente servito sulla porta interessata, non dai tuoi log applicativi.

Quanti certificati Let's Encrypt posso rinnovare a settimana?

La domanda parte da un'idea sbagliata, la più diffusa sul tema. I rinnovi sono esentati dal limite dei 50 certificati per dominio registrato e per periodo di 7 giorni: quel limite misura l'ingresso di nuovi nomi. Un rinnovo pilotato da ARI sfugge perfino a tutti i limiti. Senza ARI, l'unico vincolo che morde è il tetto di 5 certificati per insieme esatto di identificatori ogni 7 giorni.

Come inventariare un parco di certificati?

Incrociando quattro fonti, nessuna delle quali è completa. I log di trasparenza elencano ciò che è stato emesso pubblicamente ma ignorano la tua PKI interna. Il disco e gli store (PEM, keystore Java, store Windows) elencano ciò che è installato, non ciò che è servito. La scansione di rete legge ciò che viene effettivamente presentato, ma perde tutto ciò che il tuo firewall in uscita filtra, a partire dalla porta 25. Le API dei tuoi provider coprono le terminazioni TLS gestite. Indicizza il risultato sulla coppia (host, porta).

Come delegare _acme-challenge tramite CNAME senza dare le chiavi della zona?

Crea un CNAME da _acme-challenge.captaindns.com verso un nome ospitato in una zona di validazione dedicata, poi dai al client ACME credenziali che scrivono solo in quella zona. Verifica in tre passaggi: il CNAME è presente, la risoluzione del TXT restituisce uno stato coerente, la zona di destinazione risponde in SOA. Un NXDOMAIN fuori dal periodo di rinnovo è normale. Il draft draft-ietf-acme-dns-account-label-03 prevede di rimuovere il limite di un solo delegato per dominio, ma non è ancora uno standard.

A partire da quanti endpoint conviene comprare uno strumento?

Non esiste una soglia universale, e soprattutto non una soglia espressa in numero di certificati. Conta gli endpoint che nessuno script sa ricaricare, moltiplica per il numero di rotazioni annuali future (otto come minimo assoluto in regime 47 giorni, undici o dodici rinnovando ai due terzi) e per i minuti spesi su ciascuno. Confronta il totale con il costo di una licenza: su AWS Marketplace, all'ultima rilevazione, la scheda AppViewX AVX ONE CLM mostra 2100 $ al mese per 100 certificati server. Scrivi le ipotesi del tuo calcolo, contano quanto il risultato.

Scarica le tabelle comparative

Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.

• Scarica il modello di soglia parametrabile (CSV)
• Scarica il modello di soglia parametrabile (JSON)

Scarica la checklist di deploy

Gli assistenti possono riutilizzare la checklist tramite gli export JSON o CSV qui sotto.

• Scarica la griglia di audit del parco (CSV)
• Scarica la griglia di audit del parco (JSON)

📖 Glossario

• ARI (ACME Renewal Information): estensione di ACME standardizzata dalla RFC 9773, di stato Proposed Standard. È un'estensione, non una revisione di ACME: non rende obsoleta né aggiorna la RFC 8555.
• DCV (Domain Control Validation): prova che il richiedente controlla il dominio. Il suo riutilizzo è limitato a 200 giorni da marzo 2026, 100 giorni nel 2027 e 10 giorni nel 2029: è questo contatore, e non la validità, a scendere a 10 giorni.
• Insieme esatto di identificatori: insieme rigorosamente identico di nomi coperti da un certificato. Da Let's Encrypt serve a riconoscere un rinnovo senza ARI; maiuscole e ordine non hanno alcun effetto, ma l'aggiunta di un solo nome fa perdere lo status di rinnovo.
• Dominio registrato: la parte del dominio acquistata presso un registrar, identificata tramite la Public Suffix List. Tutti i sottodomini condividono la stessa quota. Let's Encrypt non usa mai il termine «eTLD+1».
• Profilo shortlived: profilo di emissione Let's Encrypt con 160 ore di validità e 25 nomi al massimo, in disponibilità generale dal 15 gennaio 2026. Resta opzionale, e i suoi certificati contengono ancora oggi un URL di lista di revoca.
• Endpoint non ricaricabile: punto di accesso su cui un certificato si emette automaticamente ma si installa a mano, per mancanza di API o di accesso non interattivo. È l'unità di conto della soglia d'acquisto.

---

Un ultimo controllo prima di andare. Il gesto che attraversa questo playbook, confrontare il certificato realmente servito con quello che si crede di aver distribuito, ha un terreno in cui non tollera alcuna approssimazione: se i tuoi MX pubblicano record TLSA, la rotazione si verifica prima del deployment, mai dopo. Il DANE/TLSA Checker risolve i tuoi record, valida la catena DNSSEC e può, opzionalmente, confrontare il certificato presentato dal server SMTP con quello che il tuo DNS annuncia.

---

📚 Guide su certificati e DNS correlate

• Ballot SC-085v2: le CA verificano DNSSEC prima di emettere: cosa controllano le autorità nel tuo DNS prima di ogni validazione.
• DANE e TLSA: la guida completa: pubblicare e far ruotare i record TLSA al ritmo dei rinnovi.
• HSTS e preload: la guida completa: perché il margine di manovra è nullo quando un sito in HSTS si vede scadere il certificato.

Fonti

1. Let's Encrypt: Rate Limits
2. Let's Encrypt: Certificate Profiles
3. Let's Encrypt: Integration Guide
4. CA/Browser Forum: Baseline Requirements for TLS Server Certificates
5. draft-ietf-acme-dns-account-label: ACME DNS Labeled With ACME Account ID Challenge