SC-081v3: certificati TLS di 47 giorni, perché e come prepararsi
Di CaptainDNS
Pubblicato il 19 marzo 2026
- SC-081v3 adottato: la durata massima dei certificati TLS passa da 398 giorni a 47 giorni entro marzo 2029, in 3 fasi (200g nel 2026, 100g nel 2027, 47g nel 2029)
- Anche il riutilizzo DCV cala drasticamente: da 398 giorni a 10 giorni, imponendo una rivalidazione del dominio quasi continua a ogni rinnovo
- L'automazione non è più opzionale: senza ACME o equivalente, il rinnovo manuale ogni 47 giorni è insostenibile
- Scopri anche come SC-085v2 impone la validazione DNSSEC da parte delle CA, una misura complementare entrata in vigore lo stesso giorno
Il 15 marzo 2026 segna un punto di svolta per l'ecosistema TLS. Due ballot del CA/Browser Forum entrano in vigore simultaneamente: SC-085v2, che impone alle autorità di certificazione di validare DNSSEC durante l'emissione dei certificati, e la prima fase di SC-081v3, che riduce la durata massima dei certificati TLS da 398 a 200 giorni. La coincidenza non è casuale: entrambi i testi partecipano alla stessa riforma della fiducia sul web.
SC-081v3 è stato adottato dal CA/Browser Forum ad aprile 2025 con un sostegno massiccio: 25 voti a favore, 0 contrari, 5 astensioni. Apple, all'origine della proposta, è stata affiancata da Google, Mozilla e Microsoft. Il messaggio è chiaro: l'era dei certificati di un anno è finita. Entro marzo 2029, la durata massima di un certificato TLS sarà di 47 giorni, e il riutilizzo delle prove di validazione del dominio (DCV) sarà limitato a 10 giorni.
Questo articolo copre la cronologia completa delle riduzioni di durata, il dettaglio del ballot SC-081v3, le ragioni tecniche di questo cambiamento, gli incidenti che hanno accelerato la decisione, l'automazione ACME, il ruolo di Let's Encrypt, l'impatto sui certificati a pagamento, l'interazione con SC-085v2 e DNSSEC, e una guida pratica per preparare la tua infrastruttura.
I tuoi rinnovi di certificati sono automatizzati?
Da 10 anni a 47 giorni: la storia della riduzione
La durata di vita dei certificati TLS non ha smesso di diminuire dalla creazione del sistema. Ogni riduzione ha provocato resistenze, poi un adattamento rapido dell'industria. Lo schema è costante: un attore impone un cambiamento, l'ecosistema si adatta e nessuno torna indietro.
Prima del 2012: fino a 10 anni. Le prime versioni dei certificati SSL non imponevano limiti rigorosi di durata. Circolavano certificati da 8 a 10 anni. La revoca si basava su liste CRL raramente consultate. Il rischio di compromissione su un periodo così lungo era considerevole, ma il costo dei certificati (diverse centinaia di dollari) incentivava a massimizzarne la durata.
2012: 5 anni (Baseline Requirements v1). Il CA/Browser Forum pubblica la prima versione dei Baseline Requirements. La durata massima viene fissata a 60 mesi. Si tratta della prima standardizzazione globale delle pratiche di emissione dei certificati TLS.
2015: 39 mesi. Il Ballot 193 riduce la durata a 39 mesi. L'industria si adatta senza incidenti significativi. I certificati di 3 anni diventano la norma per i clienti enterprise.
2018: 825 giorni. Nuova riduzione a 825 giorni (circa 27 mesi) tramite il Ballot 193 rivisto. I certificati di 2 anni si impongono. Let's Encrypt, lanciato nel 2015, ha già reso popolari i certificati di 90 giorni e dimostrato che l'automazione funziona su larga scala.
2020: 398 giorni (decisione unilaterale Apple). Apple annuncia unilateralmente a febbraio 2020 che Safari non accetterà più certificati con durata superiore a 398 giorni emessi dopo il 1 settembre 2020. Google e Mozilla seguono nelle settimane successive. Il CA/Browser Forum non ha dovuto votare: gli editori di browser hanno imposto il cambiamento tramite i loro root program. L'industria protesta, ma si adatta in pochi mesi.
2023: Google propone 90 giorni. Nella sua roadmap "Moving Forward, Together", Google propone di ridurre la durata massima a 90 giorni. La proposta non viene messa a voto immediatamente ma lancia il dibattito.
2024: SC-081v1 ritirato, v2 bocciato. La prima versione del ballot viene ritirata prima del voto. SC-081v2 viene sottoposto al voto ma non ottiene la super-maggioranza richiesta. Diverse CA si oppongono al calendario ritenuto troppo aggressivo. I ballot SC-22 e 185, che miravano a riduzioni simili, erano già falliti negli anni precedenti.
Aprile 2025: SC-081v3 adottato. La terza versione trova il consenso. Il calendario è distribuito su 4 fasi tra il 2026 e il 2029, lasciando all'industria il tempo di adattarsi. Il voto: 25 a favore, 0 contrari, 5 astensioni.
Lo schema è chiaro: ogni riduzione è stata contrastata, poi adottata, poi considerata insufficiente qualche anno dopo. La direzione è irreversibile.
Ballot SC-081v3: cosa cambia concretamente
SC-081v3 non si limita ad accorciare la durata dei certificati. Riduce anche il periodo di riutilizzo delle prove di validazione del dominio (DCV reuse), imponendo una rivalidazione quasi continua.
Le 4 fasi della riduzione
| Fase | Data di entrata in vigore | Durata max. certificato | Riutilizzo DCV max. |
|---|---|---|---|
| Fase 0 (attuale) | Prima del 15 marzo 2026 | 398 giorni | 398 giorni |
| Fase 1 | 15 marzo 2026 | 200 giorni | 200 giorni |
| Fase 2 | 15 marzo 2027 | 100 giorni | 100 giorni |
| Fase 3 | 15 marzo 2029 | 47 giorni | 10 giorni |
Comprendere il riutilizzo DCV
La validazione del controllo di dominio (DCV) è il processo con cui una CA verifica che il richiedente controlla il dominio. Attualmente, una prova DCV può essere riutilizzata per 398 giorni: se validi il tuo dominio oggi, la CA può emettere un nuovo certificato nei 398 giorni successivi senza richiedere una nuova prova.
SC-081v3 riduce questa finestra di riutilizzo parallelamente alla durata dei certificati. In fase 3, il riutilizzo DCV scende a 10 giorni. Concretamente, ogni rinnovo di certificato richiederà una nuova validazione del dominio, poiché un certificato di 47 giorni deve essere rinnovato prima della scadenza e la prova DCV sarà valida solo 10 giorni.
Perché 47 giorni e non un numero tondo?
Il numero 47 non è arbitrario. Corrisponde a un ciclo di rinnovo di 30 giorni con un margine di 17 giorni. L'idea: se il client ACME rinnova il certificato 30 giorni prima della scadenza (come raccomandano la maggior parte dei client), restano 17 giorni di margine in caso di fallimento. Un rinnovo al mese, con una rete di sicurezza di oltre due settimane.
Cosa non cambia
SC-081v3 si applica a tutti i tipi di certificati TLS pubblici: DV (Domain Validation), OV (Organization Validation) e EV (Extended Validation). Non ci sono eccezioni per i certificati OV o EV, contrariamente a quanto auspicato da alcuni commentatori. La distinzione DV/OV/EV riguarda il livello di verifica dell'identità dell'organizzazione, non la durata del certificato.
I tentativi falliti
SC-081v3 non è il primo tentativo di riduzione. Diversi ballot erano falliti nel corso degli anni. Il Ballot 185 (2017) proponeva di passare a 13 mesi e venne bocciato. Il Ballot SC-22 tentò una riduzione a 397 giorni e fallì. SC-081v1 venne ritirato prima del voto. SC-081v2 non ottenne la super-maggioranza dal lato CA. La v3 è riuscita distribuendo il calendario e aggiungendo un margine sufficiente a ogni fase.
Perché certificati più brevi?
La riduzione della durata dei certificati risponde a diversi problemi strutturali dell'ecosistema TLS. Nessuno di essi può essere risolto con i meccanismi attuali.
La revoca è inefficace
Il meccanismo previsto per invalidare un certificato compromesso non funziona nella pratica. Le liste di revoca (CRL) raggiungono centinaia di megabyte: la CRL di Let's Encrypt superava i 300 MB prima dell'abbandono di OCSP. OCSP (Online Certificate Status Protocol) soffre del problema del soft-fail: se il server OCSP non risponde, il browser accetta comunque il certificato, rendendo la verifica inutile. Chrome ha sostituito OCSP con CRLSets, una lista compatta che copre solo circa il 2% dei certificati revocati. Let's Encrypt ha ufficialmente abbandonato OCSP a fine 2024, riconoscendo il fallimento del meccanismo.
Con certificati di 47 giorni, la revoca diventa meno critica. Un certificato compromesso scade naturalmente in poche settimane, limitando la finestra di sfruttamento senza dipendere da un meccanismo di revoca difettoso.
Criptoagilità e migrazione post-quantistica
Certificati brevi facilitano la migrazione verso nuovi algoritmi crittografici. Il NIST ha pubblicato nell'agosto 2024 gli standard finali per la crittografia post-quantistica: ML-KEM (Key Encapsulation) e ML-DSA (Digital Signatures). La transizione verso questi algoritmi richiederà la sostituzione dei certificati esistenti. Con certificati di 47 giorni, l'intero ecosistema migra in massimo 47 giorni, contro oltre un anno con certificati di 398 giorni.
Finestra di compromissione ridotta
Un certificato compromesso di 398 giorni può essere sfruttato per oltre un anno. Con 47 giorni, la finestra massima di sfruttamento scende a meno di 7 settimane. Si tratta di una riduzione dell'88%. Se una chiave privata viene rubata, l'attaccante dispone di poche settimane invece di oltre un anno per sfruttarla.
L'automazione forzata riduce le interruzioni
Paradossalmente, certificati più brevi riducono le interruzioni legate alla scadenza. Il motivo: obbligano all'automazione. Un certificato di 398 giorni può essere gestito manualmente (male), dimenticato, poi scadere bruscamente. Un certificato di 47 giorni non lascia scelta: senza automazione, il rinnovo è impossibile da mantenere. Le organizzazioni che automatizzano non subiscono più interruzioni dovute alla scadenza.
Allineamento con il modello zero trust
Il modello Zero Trust si basa sulla verifica continua. Un certificato di 398 giorni concede una fiducia implicita per oltre un anno, il che contraddice il principio. Certificati brevi impongono una ri-verifica frequente dell'identità del server, allineando la PKI web con i principi Zero Trust.
Gli incidenti che hanno cambiato tutto
Diversi incidenti gravi hanno dimostrato le conseguenze di una gestione manuale dei certificati. Ogni interruzione ha rafforzato l'argomento a favore dell'automazione e della riduzione della durata.
Equifax (2017): 147,9 milioni di persone esposte
A marzo 2015, Equifax lascia scadere un certificato SSL su un apparecchio di ispezione del traffico di rete. Questo certificato scaduto da 19 mesi impedisce il rilevamento di un'intrusione attiva. Gli attaccanti sfruttano una vulnerabilità Apache Struts non corretta per 76 giorni, esfiltrando i dati personali di 147,9 milioni di persone. Il costo totale supera 1,38 miliardi di dollari. L'indagine rivela che l'azienda gestiva più di 300 certificati manualmente, senza inventario centralizzato.
Ericsson/O2 UK (2018): 32 milioni di utenti senza rete
Il 6 dicembre 2018, un certificato intermedio Ericsson scade nell'infrastruttura di rete di O2 UK. La scadenza provoca un'interruzione totale della rete mobile per 32 milioni di abbonati per oltre 12 ore. SoftBank in Giappone subisce un'interruzione identica lo stesso giorno. Il costo stimato supera i 133 milioni di dollari. Il certificato, con una durata di 15 anni, era stato installato e dimenticato.
Microsoft Teams (2020): 3 ore di interruzione globale
Il 3 febbraio 2020, Microsoft Teams subisce un'interruzione di 3 ore in piena crescita di utilizzo legata al COVID-19. La causa: un certificato di autenticazione scaduto. L'incidente colpisce milioni di utenti in telelavoro nel momento in cui Teams era diventato uno strumento critico per migliaia di aziende.
Let's Encrypt (2021): la scadenza di un certificato root storico
Il 30 settembre 2021, il certificato root DST Root CA X3, utilizzato da Let's Encrypt per la compatibilità con i dispositivi più vecchi, scade. Milioni di dispositivi con Android 7.1 e versioni precedenti perdono l'accesso ai siti che utilizzano Let's Encrypt. L'incidente illustra la complessità della gestione dei certificati root e la necessità di catene di fiducia agili.
Il punto in comune di questi incidenti: ogni interruzione coinvolge un certificato gestito manualmente, dimenticato, o la cui durata di vita superava largamente le esigenze operative.
ACME e l'automazione obbligatoria
Con certificati di 47 giorni e un riutilizzo DCV di 10 giorni, il rinnovo manuale diventa fisicamente impossibile per qualsiasi infrastruttura con più di una manciata di certificati. ACME (Automatic Certificate Management Environment) è il protocollo che rende possibile l'automazione.
Il protocollo ACME (RFC 8555)
ACME standardizza il dialogo tra un client (il tuo server) e una CA. Il processo segue tre fasi: il client dimostra di controllare il dominio (challenge), la CA verifica la prova, poi emette il certificato. Esistono tre tipi di challenge:
- HTTP-01: il client inserisce un file a un URL specifico. La CA verifica che il file sia accessibile. Semplice ma incompatibile con i certificati wildcard.
- DNS-01: il client pubblica un record TXT sotto
_acme-challenge.captaindns.com. La CA interroga il DNS. Compatibile wildcard, ideale per gli ambienti automatizzati. - TLS-ALPN-01: il client configura un certificato temporaneo con un'estensione ALPN specifica. Utile quando non si controlla né il DNS né il server web.
Client ACME
L'ecosistema dei client ACME è maturo e copre tutti gli ambienti:
- Certbot: il client di riferimento, mantenuto dalla EFF. Compatibile con Linux, macOS, Windows. Plugin per Apache e NGINX.
- acme.sh: script shell puro, senza dipendenze. Oltre 150 API DNS supportate per il challenge dns-01.
- Lego: client Go, popolare negli ambienti containerizzati e nelle pipeline CI/CD.
- Caddy: server web con ACME integrato. Ottiene e rinnova i certificati automaticamente, senza configurazione.
- Traefik: reverse proxy cloud-native con ACME integrato. Gestisce i certificati per tutti i backend.
ACME nel cloud
I principali fornitori cloud integrano l'automazione dei certificati:
- AWS Certificate Manager (ACM): certificati gratuiti con rinnovo automatico per i servizi AWS (ALB, CloudFront, API Gateway).
- Google Cloud Managed Certificates: rinnovo automatico per i load balancer GCP.
- Azure App Service Managed Certificates: certificati gratuiti e rinnovati automaticamente.
- Cloudflare: certificati edge e origin gestiti automaticamente, con supporto per certificati di 15 giorni.
ACME renewal information (ARI, RFC 9773)
ARI è un'estensione ACME che permette alla CA di comunicare al client la finestra ottimale di rinnovo. Invece di rinnovare sistematicamente a una percentuale fissa della durata residua, il client interroga la CA per conoscere il momento ideale. Questo permette alla CA di distribuire il carico e di segnalare un rinnovo anticipato in caso di compromissione della chiave. Let's Encrypt supporta ARI dal 2024.
NGINX e il modulo ACME nativo
Ad agosto 2025, NGINX ha pubblicato un modulo nativo ACME che permette al server web di ottenere e rinnovare i propri certificati direttamente, senza client esterno. Questa integrazione semplifica notevolmente il deployment per gli ambienti che utilizzano NGINX come frontend.
Soluzioni enterprise
Per le grandi organizzazioni che gestiscono migliaia di certificati, le soluzioni CLM (Certificate Lifecycle Management) orchestrano il rinnovo su larga scala:
- HashiCorp Vault PKI: motore PKI integrato in Vault, con emissione e rotazione automatizzate.
- Venafi / CyberArk: piattaforma CLM enterprise (CyberArk ha acquisito Venafi per 1,54 miliardi di dollari nel 2024).
- Keyfactor: piattaforma di gestione del ciclo di vita dei certificati e delle identità macchina.
- Sectigo Certificate Manager: CLM con ACME integrato, che copre certificati pubblici e privati.
Let's Encrypt come apripista
Let's Encrypt non ha atteso SC-081v3 per spingere l'industria verso certificati brevi. L'autorità di certificazione gratuita e automatizzata detiene circa il 63,9% di quota di mercato dei certificati TLS web e rilascia più di 10 milioni di certificati al giorno. La sua influenza sull'ecosistema è considerevole.
Certificati di 6 giorni in produzione
Da gennaio 2026, Let's Encrypt propone certificati di 6 giorni in disponibilità generale. Questi certificati ultra-brevi sono destinati agli ambienti altamente automatizzati (CDN, piattaforme cloud, CI/CD) dove il rinnovo è interamente pilotato da ACME. L'obiettivo: dimostrare che durate di vita molto brevi funzionano su scala industriale.
Verso certificati di 45 giorni di default
Let's Encrypt ha annunciato un piano di transizione verso certificati di 45 giorni di default. Il calendario prevede una fase opt-in a partire da maggio 2026, seguita da un passaggio al default di 45 giorni a febbraio 2028. Questa anticipazione del calendario SC-081v3 (che impone 47 giorni a marzo 2029) offre all'ecosistema un anno di vantaggio per validare le pipeline di automazione.
L'abbandono di OCSP
A fine 2024, Let's Encrypt ha annunciato l'abbandono progressivo di OCSP, completato nel 2025. Il motivo: OCSP non funziona (soft-fail nei browser, problemi di privacy, carico sul server). Questa scelta ha accelerato la riflessione dell'industria sulla revoca e rafforzato l'argomento dei certificati brevi. Se la revoca non funziona, l'unica alternativa è limitare la durata di vita dei certificati.
Let's Encrypt dimostra ogni giorno che l'automazione su larga scala è fattibile. Oltre 400 milioni di siti web utilizzano i suoi certificati. Il passaggio a 47 giorni non sarà un problema per gli ambienti già automatizzati: sarà un non-evento.
Impatto sui certificati a pagamento e sull'ecosistema CA
SC-081v3 trasforma il modello economico delle autorità di certificazione e rimette in discussione il valore aggiunto dei certificati a pagamento.
OV e EV: ancora validi, ma più brevi
I certificati OV (Organization Validation) e EV (Extended Validation) rimangono disponibili. La validazione dell'organizzazione (verifica dell'identità dell'azienda, indirizzo, numero di registrazione) continua ad apportare un valore distinto dalla semplice validazione del dominio. Ma la durata del certificato si riduce allo stesso modo: 200 giorni nel 2026, 100 giorni nel 2027, 47 giorni nel 2029. Un certificato EV di 47 giorni impone lo stesso ritmo di rinnovo di un certificato DV.
Il pivot verso gli abbonamenti e il CLM
Le CA a pagamento stanno trasformando il loro modello economico. Invece di vendere certificati singoli a durata fissa, propongono abbonamenti annuali che includono rinnovi illimitati e un client ACME integrato. DigiCert, Sectigo e GlobalSign propongono tutti piattaforme CLM (Certificate Lifecycle Management) che automatizzano il rinnovo ACME per i certificati OV e EV.
La consolidazione del mercato CA
L'acquisizione di Venafi da parte di CyberArk per 1,54 miliardi di dollari nel 2024 illustra la consolidazione del mercato. Il valore si sposta dall'emissione di certificati verso la gestione del ciclo di vita. Le CA che non propongono un'automazione integrata perdono quote di mercato a vantaggio di Let's Encrypt e delle soluzioni CLM.
Wildcard e multi-SAN
I certificati wildcard (*.captaindns.com) e multi-SAN (più domini su un singolo certificato) richiedono il challenge DNS-01 per la validazione. Con rinnovi ogni 47 giorni, l'automazione del challenge dns-01 tramite l'API del fornitore DNS diventa indispensabile. I principali fornitori DNS (Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS) propongono tutti API compatibili con i client ACME.
L'automazione rimette in discussione il certificato a pagamento
L'automazione ACME livella il terreno di gioco. Un certificato DV gratuito Let's Encrypt, rinnovato automaticamente ogni 47 giorni, offre lo stesso livello di cifratura di un certificato EV a pagamento. La differenza si limita alla barra degli indirizzi del browser (che dal 2019 non mostra più il nome dell'organizzazione) e alla garanzia finanziaria associata al certificato. Per la maggior parte dei siti web, questa differenza non giustifica più il sovrapprezzo.
Interazione con SC-085v2: DNSSEC e rinnovi frequenti
SC-081v3 e SC-085v2 entrano in vigore lo stesso mese e creano un effetto moltiplicatore sulla catena di fiducia DNS. Per comprendere SC-085v2 nel dettaglio, consulta il nostro articolo dedicato.
L'effetto moltiplicatore
Con SC-085v2, ogni validazione del dominio (DCV) include ora una verifica DNSSEC. Con SC-081v3 fase 3, un certificato di 47 giorni implica circa 8 rinnovi all'anno invece di 1. Ogni rinnovo attiva una DCV, e ogni DCV verifica DNSSEC. Il numero di verifiche DNSSEC legate ai certificati viene quindi moltiplicato per 8.
Scenario di interruzione: DNSSEC guasto + certificati brevi
Consideriamo uno scenario concreto. Il tuo certificato TLS scade tra 15 giorni. Il tuo client ACME tenta il rinnovo. La CA effettua la validazione DNS-01 e verifica DNSSEC conformemente a SC-085v2. Ma una rotazione di chiave DNSSEC è fallita: il record DS al TLD non corrisponde più alla KSK della tua zona. Il resolver della CA restituisce BOGUS, la DCV fallisce, il certificato non viene rinnovato.
Con un certificato di 398 giorni, hai mesi per individuare e correggere il problema. Con un certificato di 47 giorni, hai al massimo 17 giorni (il margine integrato nel ciclo di rinnovo). Se il problema DNSSEC persiste, il tuo certificato scade e il tuo sito diventa irraggiungibile.
Rotazione DANE/TLSA e certificati brevi
Se utilizzi DANE per autenticare i tuoi certificati TLS tramite record TLSA firmati con DNSSEC, la rotazione dei record TLSA deve seguire il ritmo dei rinnovi di certificato. Con un certificato di 47 giorni, il record TLSA deve essere aggiornato a ogni rinnovo (tranne in modalità DANE-EE 3 1 1 con SPKI, che sopravvive al rinnovo se la chiave pubblica non cambia). Consulta la nostra guida DANE/TLSA per le strategie di rotazione.
Pipeline unificata: la raccomandazione
La combinazione SC-081v3 + SC-085v2 impone un approccio unificato. La pipeline di rinnovo dei certificati deve integrare:
- Il rinnovo ACME del certificato TLS
- La verifica preliminare della catena DNSSEC
- L'aggiornamento dei record DANE/TLSA se necessario
- Il monitoraggio continuo dei tre componenti
Trattare questi elementi separatamente moltiplica i punti di fallimento. Una pipeline unificata che verifica DNSSEC prima di lanciare il rinnovo ACME, poi aggiorna TLSA dopo l'emissione, riduce notevolmente il rischio di interruzione.
Guida pratica: preparare la tua infrastruttura
La transizione verso certificati di 47 giorni avviene in 4 fasi su 3 anni. Ogni fase impone vincoli più rigidi. Ecco i 6 passaggi per preparare la tua infrastruttura.
Passaggio 1: inventariare tutti i tuoi certificati
Prima di automatizzare, devi sapere cosa gestisci. Usa più fonti per stilare un inventario completo:
- Certificate Transparency logs: interroga i log CT (crt.sh) per elencare tutti i certificati emessi per i tuoi domini.
- Scansione di rete: usa strumenti come
sslyzeonmapper scoprire i certificati attivi sulla tua infrastruttura. - Strumenti CLM: piattaforme come Keyfactor o Venafi Discovery scansionano la tua rete e i tuoi cloud per identificare certificati non censiti.
- Il nostro DNSSEC Checker: verifica la catena di fiducia DNSSEC, indispensabile per il rinnovo dei certificati da SC-085v2.
Documenta per ogni certificato: il dominio, la CA emittente, la data di scadenza, il tipo (DV/OV/EV), la modalità di rinnovo (manuale o automatizzato) e il responsabile.
Passaggio 2: distribuire un client ACME adatto
Scegli un client ACME adatto al tuo ambiente:
- Server web standalone: Certbot con il plugin appropriato (Apache, NGINX) oppure Caddy con ACME integrato.
- Ambiente containerizzato: cert-manager per Kubernetes, Lego per le pipeline CI/CD.
- Infrastruttura cloud: AWS ACM, Google Cloud Managed Certificates o Azure App Service Managed Certificates.
- Ambiente misto: acme.sh per la sua flessibilità e compatibilità con oltre 150 API DNS.
Testa il rinnovo con un dry-run prima di passare in produzione. Verifica che il client possa rinnovare senza intervento umano.
Passaggio 3: automatizzare la validazione DNS
Per il challenge dns-01 (richiesto per i certificati wildcard), il tuo client ACME deve poter creare e cancellare record TXT tramite l'API del tuo fornitore DNS. Configura gli accessi API con permessi minimi: creazione e cancellazione di record TXT sotto _acme-challenge unicamente.
Se il tuo fornitore DNS non offre un'API, migra verso un fornitore che la offre. Nel 2026, l'assenza di un'API DNS è un fattore bloccante.
Passaggio 4: verificare la tua catena DNSSEC
Con SC-085v2, una catena DNSSEC rotta blocca il rinnovo dei certificati. Verifica:
- La presenza e la validità del record DS al TLD
- La coerenza tra il DS e la KSK pubblicata nella tua zona
- La validità delle firme RRSIG (date di scadenza)
- L'automazione della rotazione delle chiavi ZSK e KSK
Consulta la nostra guida sulla catena di fiducia DNSSEC per i dettagli tecnici. Usa il DNSSEC Checker per una diagnosi completa.
Passaggio 5: impostare il monitoraggio
Distribuisci allarmi su tre assi:
- Scadenza dei certificati TLS: allarme a 30 giorni, 14 giorni e 7 giorni prima della scadenza.
- Firme DNSSEC (RRSIG): allarme quando le firme si avvicinano alla data di scadenza.
- Record DANE/TLSA: verifica che i record TLSA corrispondano al certificato attivo.
Il monitoraggio è la rete di sicurezza che rileva i fallimenti dell'automazione prima che diventino interruzioni.
Passaggio 6: pianificare la migrazione progressiva
Non attendere marzo 2029 per passare a 47 giorni. Adotta un piano progressivo:
- Da subito: automatizza tutti i certificati con durate di 90 giorni (Let's Encrypt di default).
- 2026: testa i certificati di 6 giorni di Let's Encrypt in un ambiente di staging.
- 2027: passa in produzione con certificati di 100 giorni o meno.
- 2028: attiva i certificati di 45 giorni Let's Encrypt (opt-in) per validare la tua pipeline prima della scadenza.
- 2029: il passaggio a 47 giorni è un non-evento, la tua infrastruttura è pronta.
Piano d'azione: preparare la tua infrastruttura
- Inventariare tutti i tuoi certificati: discovery tramite CT log, scansione di rete, strumenti CLM
- Distribuire un client ACME: Certbot, acme.sh o Lego secondo l'ambiente
- Automatizzare la validazione DNS: API del fornitore DNS per il challenge dns-01
- Verificare DNSSEC: catena di fiducia valida, rotazioni di chiavi automatizzate
- Impostare il monitoraggio: allarmi scadenza certificati + RRSIG + TLSA
- Testare con certificati brevi: Let's Encrypt 90g poi 6g per validare la pipeline
FAQ
Cos'è il Ballot SC-081v3 del CA/Browser Forum?
SC-081v3 è un ballot adottato ad aprile 2025 dal CA/Browser Forum che riduce progressivamente la durata massima dei certificati TLS pubblici. La durata passa da 398 giorni a 200 giorni (marzo 2026), poi 100 giorni (marzo 2027), poi 47 giorni (marzo 2029). Riduce anche il periodo di riutilizzo delle prove di validazione del dominio (DCV) fino a 10 giorni nella fase finale.
Quando diventano obbligatori i certificati di 47 giorni?
I certificati di 47 giorni massimo diventano obbligatori il 15 marzo 2029 (fase 3 del ballot). Prima di quella data, si applicano due fasi intermedie: 200 giorni massimo dal 15 marzo 2026 e 100 giorni massimo dal 15 marzo 2027. I certificati emessi prima di ogni scadenza restano validi fino alla loro naturale scadenza.
I miei certificati attuali verranno revocati?
No. I certificati già emessi restano validi fino alla loro data di scadenza, indipendentemente dalla fase in corso. SC-081v3 si applica unicamente ai nuovi certificati emessi dopo ogni data di entrata in vigore. Un certificato di 398 giorni emesso il 14 marzo 2026 resterà valido per tutta la sua durata.
Perché 47 giorni e non un numero tondo?
Il numero 47 corrisponde a un ciclo di rinnovo di 30 giorni più un margine di 17 giorni. Se il client ACME rinnova 30 giorni prima della scadenza (la pratica raccomandata), restano 17 giorni di margine in caso di fallimento del rinnovo. Questo margine permette di individuare e correggere i problemi prima della scadenza effettiva del certificato.
I certificati EV e OV sono interessati?
Sì. SC-081v3 si applica a tutti i tipi di certificati TLS pubblici, compresi DV, OV e EV. Non ci sono eccezioni. La distinzione tra questi tipi riguarda il livello di verifica dell'identità dell'organizzazione, non la durata del certificato. Un certificato EV sarà limitato a 47 giorni come un certificato DV a partire da marzo 2029.
Cos'è la riduzione del riutilizzo DCV?
Il riutilizzo DCV (Domain Control Validation) permette a una CA di riutilizzare una prova di controllo del dominio per emettere più certificati senza richiedere una nuova validazione. SC-081v3 riduce questa finestra da 398 giorni a 10 giorni nella fase finale. Concretamente, ogni rinnovo di certificato nella fase 3 richiederà una nuova prova di controllo del dominio.
Devo passare a Let's Encrypt?
Non necessariamente. Let's Encrypt è un'opzione solida per i certificati DV automatizzati, ma anche altre CA supportano ACME: DigiCert, Sectigo, GlobalSign e ZeroSSL propongono tutti endpoint ACME. Se hai bisogno di certificati OV o EV, dovrai restare presso una CA a pagamento, ma con un client ACME per il rinnovo automatizzato.
Come funziona ACME per il rinnovo automatico?
ACME (RFC 8555) automatizza il dialogo tra il tuo server e la CA. Il client ACME dimostra che controlli il dominio (tramite un challenge HTTP-01, DNS-01 o TLS-ALPN-01), la CA verifica la prova, poi emette il certificato. Il client pianifica poi il rinnovo automatico prima della scadenza. L'intero processo avviene senza intervento umano.
Qual è il legame tra SC-081v3 e SC-085v2 (DNSSEC)?
SC-085v2 impone alle CA di validare DNSSEC durante la DCV. SC-081v3 moltiplica le DCV accorciando la durata dei certificati. Combinati, questi due ballot creano un effetto moltiplicatore: 8 rinnovi all'anno (47 giorni) significano 8 verifiche DNSSEC invece di 1. Un DNSSEC guasto blocca quindi più rapidamente e più frequentemente il rinnovo dei tuoi certificati.
I certificati interni (PKI privata) sono interessati?
No. SC-081v3 si applica unicamente ai certificati emessi da CA pubblicamente approvate (quelle il cui certificato root è incluso nei trust store dei browser). I certificati emessi da una PKI privata interna alla tua organizzazione non sono soggetti ai Baseline Requirements del CA/Browser Forum e non sono interessati da questa riduzione.
Glossario
- CA/Browser Forum: consorzio che riunisce le autorità di certificazione e gli editori di browser. Pubblica i Baseline Requirements, il quadro normativo che tutte le CA pubbliche devono rispettare affinché i loro certificati vengano accettati dai browser.
- Ballot: proposta di modifica dei Baseline Requirements sottoposta al voto dei membri del CA/Browser Forum. Un ballot deve ottenere una super-maggioranza dal lato CA e l'unanimità dal lato browser per essere adottato.
- DCV (Domain Control Validation): processo con cui una CA verifica che il richiedente di un certificato controlla effettivamente il dominio. I metodi comuni sono DNS-01, HTTP-01 e email. Il riutilizzo DCV permette di riutilizzare una prova esistente per emissioni successive.
- ACME (Automatic Certificate Management Environment): protocollo standardizzato (RFC 8555) per l'automazione dell'emissione e del rinnovo dei certificati TLS. Utilizzato da Let's Encrypt, certbot, acme.sh, Lego e cert-manager.
- CRL (Certificate Revocation List): lista di certificati revocati pubblicata da una CA. Le CRL sono voluminose (diverse centinaia di MB) e raramente consultate dai browser, il che ne limita l'efficacia.
- OCSP (Online Certificate Status Protocol): protocollo di verifica in tempo reale dello stato di revoca di un certificato. Nella pratica, i browser ignorano gli errori OCSP (soft-fail), rendendo il meccanismo inefficace. Let's Encrypt ha abbandonato OCSP nel 2025.
- Criptoagilità: capacità di un sistema di migrare rapidamente verso nuovi algoritmi crittografici. Certificati brevi facilitano questa migrazione limitando il periodo durante il quale un algoritmo obsoleto resta in servizio.
- DANE/TLSA: protocollo che permette di pubblicare nel DNS (tramite record TLSA firmati con DNSSEC) il certificato atteso su un server. Elimina la dipendenza dalle CA per l'autenticazione del certificato.
