Aggiornamento Chrome Policy 2026: obbligo di CT Logging per i certificati TLS DigiCert
Se la tua organizzazione usa certificati TLS pubblici emessi da DigiCert, GeoTrust, Thawte, RapidSSL o Encryption Everywhere, la novità più importante è semplice: dal giugno 2026 il Certificate Transparency (CT) Logging diventa obbligatorio per questi certificati. Se oggi stai escludendo il CT Logging, il passo più utile da fare subito è controllare le tue policy di emissione e preparare la transizione.
In pratica, questo aggiornamento può influire sul modo in cui i certificati vengono rilasciati e pubblicati. Per la maggior parte dei team tecnici, la risposta operativa è chiara: rivedi le impostazioni del tuo account, verifica i flussi di rilascio e aggiorna i processi prima della scadenza.
Cosa cambia in concreto
Il cambiamento riguarda i certificati TLS pubblici emessi tramite alcuni marchi del gruppo DigiCert. Se in precedenza la tua organizzazione aveva scelto di non includere il CT Logging, questa opzione non sarà più compatibile con la nuova policy per i certificati interessati.
Il Certificate Transparency è un meccanismo che rende i certificati pubblicati in registri pubblici, così da aumentare la visibilità e facilitare il controllo dell’ecosistema SSL/TLS. Per questo motivo, la direzione generale del settore è verso una maggiore trasparenza e una riduzione delle eccezioni.
Chi dovrebbe prestare attenzione
Questo aggiornamento è particolarmente rilevante per:
- aziende che emettono certificati per siti web pubblici
- team IT che gestiscono infrastrutture con rinnovi automatici
- agenzie e system integrator che amministrano più domini per clienti diversi
- organizzazioni che usano policy personalizzate per il rilascio dei certificati
- realtà che hanno storicamente escluso il CT Logging per specifiche esigenze operative
Se lavori con grandi volumi di certificati, anche un piccolo cambiamento nella policy può avere effetti su automazioni, approvazioni e distribuzione.
Perché questa modifica è importante
Molte organizzazioni trattano i certificati SSL/TLS come una componente invisibile dell’infrastruttura. Funzionano, quindi tendono a passare in secondo piano. Quando però una policy cambia, il rischio non è teorico: possono comparire ritardi nei rinnovi, errori nei processi di emissione o certificati non conformi alle nuove regole.
Per questo è utile leggere l’aggiornamento non solo come una variazione tecnica, ma come un segnale operativo. Le organizzazioni che agiscono per tempo riducono il rischio di problemi nei giorni precedenti alla scadenza o durante le finestre di rinnovo automatico.
Azioni consigliate subito
Se gestisci certificati coinvolti da questa policy, ecco l’approccio più prudente:
- identifica tutti i certificati pubblici emessi con i brand interessati
- verifica se in passato è stata attivata un’esclusione del CT Logging
- controlla i flussi di rinnovo manuali e automatici
- aggiorna eventuali documentazioni interne e runbook
- informa chi gestisce DNS, hosting, CDN e deployment dei certificati
- esegui un test di rinnovo prima della scadenza effettiva
Queste verifiche aiutano a evitare sorprese quando la nuova regola diventerà effettiva.
Effetti pratici per i team non tecnici
Anche senza entrare nei dettagli dell’infrastruttura, il messaggio per i responsabili di business è semplice: i certificati web vanno controllati ora, non all’ultimo momento. Se la tua azienda usa servizi esterni o piattaforme gestite da terze parti, conviene chiedere conferma che la nuova policy sia già stata recepita.
In molte organizzazioni, infatti, il certificato è gestito da un fornitore, mentre il sito o il portale finale è gestito internamente. In questi casi, la responsabilità operativa è condivisa e una verifica preventiva evita interruzioni di servizio.
Come prepararsi senza complicare il lavoro
Un piano pratico può essere molto semplice:
- crea un inventario dei domini interessati
- identifica il tipo di certificato usato per ciascun dominio
- verifica con il fornitore se il CT Logging è già previsto
- pianifica un rinnovo di prova in un ambiente controllato
- documenta la nuova procedura per i rinnovi futuri
Se il tuo ambiente è centralizzato, coinvolgi subito chi gestisce PKI, DevOps o sicurezza. Se invece i certificati sono distribuiti tra più reparti, conviene assegnare un referente unico per evitare errori di coordinamento.
Impatto su SEO, fiducia e continuità del servizio
Anche se il cambiamento nasce da una policy tecnica, gli effetti possono toccare aspetti molto visibili. Un sito che perde la validità del certificato può mostrare avvisi di sicurezza ai visitatori, con conseguenze sulla fiducia e sulla permanenza degli utenti. Per questo l’aggiornamento non riguarda solo i team di sicurezza, ma anche chi presidia l’esperienza del cliente e la continuità digitale.
Dal punto di vista SEO, la priorità non è il ranking in sé, ma la stabilità del sito. Un certificato non valido può bloccare l’accesso o generare interruzioni che peggiorano la percezione del brand e riducono il traffico utile.
Technical Deep Dive
Per i tecnici, il punto centrale è che il Certificate Transparency rende i certificati pubblici osservabili attraverso log append-only, progettati per aumentare auditabilità e rilevazione di emissioni improprie. Quando un’autorità di certificazione impone il CT Logging come requisito, l’emissione deve includere i dati necessari affinché il certificato sia conforme alle policy del browser e dell’ecosistema di fiducia.
Nel contesto dei certificati TLS pubblici, questo significa che i processi di issuance devono essere allineati a:
- catene di certificazione supportate dal browser
- presenza di SCT validi, ove richiesti
- automazioni ACME o API compatibili con la nuova policy
- configurazioni interne che non forzino esclusioni del CT Logging
Se la tua infrastruttura usa piattaforme di provisioning, load balancer, WAF o CDN, il controllo non deve limitarsi al certificato finale. È necessario verificare anche dove avviene la richiesta iniziale, chi firma la richiesta, come viene gestito il rinnovo e se esistono template o profili che impongono impostazioni obsolete.
Un ulteriore punto da considerare è la differenza tra ambienti di test e produzione. In molti casi i test usano certificati con configurazioni diverse, quindi un rinnovo riuscito in staging non garantisce che la produzione sia già pronta. La strategia corretta è allineare i profili di emissione, validare il comportamento del fornitore e documentare i cambiamenti nel sistema di change management.
Per gli ambienti multi-dominio o ad alto volume, conviene anche verificare:
- eventuali dipendenze da certificati wildcard
- rotazioni programmate in finestre di manutenzione
- integrazioni con secret manager e sistemi CI/CD
- alert su scadenza certificati e fallimenti di rinnovo
- responsabilità tra security, network e piattaforme applicative
In sintesi tecnica, la priorità è ridurre il rischio di mismatch tra policy del fornitore, automazione interna e configurazioni legacy. Un controllo anticipato consente di aggiornare i profili prima che il rilascio venga bloccato o che il rinnovo fallisca in produzione.
