Autenticazione con certificati pubblici? Basta. Cosa è necessario cambiare entro il 2026
Entro maggio 2026, le autorità di certificazione pubbliche (CA) smetteranno di supportare l'autenticazione client TLS a causa delle nuove regole del programma root di Chrome. Le organizzazioni che si affidano a certificati SSL/TLS pubblici per l'autenticazione di utenti, dispositivi o applicazioni dovranno passare a CA private. Questo cambiamento avrà un impatto su VPN, mTLS, onboarding Wi-Fi e altro ancora. Le moderne soluzioni CA private, combinate con la gestione del ciclo di vita dei certificati (CLM), offrono un percorso sicuro e scalabile per il futuro.
Nel maggio 2026, si verificherà un cambiamento fondamentale nell'infrastruttura a chiave pubblica (PKI), che la maggior parte delle organizzazioni non sta monitorando, ma che molti avvertiranno. A causa dei requisiti aggiornati del programma Chrome Root e dei recenti annunci delle autorità di certificazione (CA), le CA pubbliche non emetteranno più certificati che supportano l'autenticazione client TLS.
Per le organizzazioni che si affidano a questi certificati per autenticare utenti, dispositivi o applicazioni, questa modifica introduce una scadenza inderogabile. I flussi di lavoro di autenticazione esistenti, in particolare quelli che si affidano silenziosamente a CA pubbliche gratuite o automatizzate, inizieranno a fallire a meno che le organizzazioni non migrino a CA private.
Questo cambiamento non è un aggiornamento di politica marginale. Si tratta di un riallineamento strutturale che ridefinisce il modo in cui l'autenticazione deve essere gestita nell'infrastruttura aziendale. E arriva molto prima di quanto la maggior parte delle persone si renda conto.
Il cambiamento di politica alla base di tutto
L'origine di questo cambiamento risiede nella Chrome Root Program Policy 1.6, che impone che le gerarchie di certificati incluse nell'archivio di fiducia di Chrome siano dedicate esclusivamente all'autenticazione dei server TLS entro giugno 2026. In breve, le CA pubbliche non saranno più autorizzate a emettere certificati che contengono entrambi gli Extended Key Usages (EKU) id-kp-serverAuth e id-kp-clientAuth. Questi EKU definiscono l'uso consentito di un certificato e, in questo caso, l'autenticazione del server o del client.
L'applicazione è già in corso.
Sectigo ha annunciato che a partire dal 15 settembre 2025 non includerà più l'EKU Client Authentication per impostazione predefinita nei certificati SSL/TLS di nuova emissione. Entro il 15 maggio 2026, Sectigo rimuoverà definitivamente l'EKU Client Authentication da tutti i certificati SSL/TLS di nuova emissione. Dopo tale data non saranno concesse eccezioni.
Questo cambiamento di politica segue una tendenza più ampia dei browser che non tollerano alcuna revoca ritardata. Anziché continuare a tollerare certificati pubblici ad uso misto, Chrome ha optato per la chiarezza: la PKI pubblica è solo per l'autenticazione del server. Se è necessaria l'autenticazione del client, utilizzare una CA.
Che cos'è l'autenticazione client TLS e perché potreste utilizzarla
L'autenticazione client TLS consente ai sistemi di verificare l'identità di client, utenti, dispositivi o applicazioni quando tentano di connettersi a un server. È diversa dalla più nota autenticazione server TLS (utilizzata in HTTPS), che verifica i siti web.
Alcuni casi d'uso comuni includono:
- Accesso VPN per l'emissione di certificati ai laptop dei dipendenti per verificare la loro identità quando si connettono da remoto.
- Onboarding Wi-Fi per autenticare i dispositivi dei dipendenti e proteggere le reti senza condividere password statiche.
- Accesso a Salesforce o altri flussi di lavoro SSO che si basano su certificati client incorporati nei dispositivi endpoint.
- Mutual TLS (mTLS) per API, in particolare nelle pipeline CICD o tra microservizi in architetture zero-trust.
- Identità dei dispositivi o dei carichi di lavoro in ambienti DevOps, inclusi i servizi basati su container.
Il problema principale è questo: molte organizzazioni utilizzano inconsapevolmente CA pubbliche per l'autenticazione dei client in questi flussi di lavoro, spesso perché è facile, economico o incluso in strumenti di automazione come ACME.
Google Chrome ha reso la rimozione dell'autenticazione dei client una condizione preliminare per che le radici rimangano nel Chrome Root Store. Poiché la maggior parte degli altri browser segue gli stessi programmi di root, i certificati di autenticazione dei client realmente affidabili a livello globale scompariranno.
Una volta che le principali CA pubblicamente affidabili avranno completato la rimozione degli EKU di autenticazione client dalle loro linee TLS nel 2025/2026, le organizzazioni che ancora si affidano a un certificato di autenticazione client TLS per identificare i client avranno difficoltà (e presto sarà impossibile) trovare dei sostituti. Tutte le grandi CA pubbliche hanno ora pubblicato un calendario di dismissione.
CA private moderne: non più un compito arduo come un tempo
L'autenticazione client è fondamentalmente una funzione di sicurezza interna. Richiede flessibilità, controllo granulare e la garanzia che i certificati non vengano revocati da modifiche alle politiche esterne. Le CA pubbliche non sono mai state progettate per questo scopo.
Fino a poco tempo fa, molte organizzazioni le utilizzavano comunque, spesso senza rendersi conto delle implicazioni. I certificati pubblici erano facili da ottenere, automatizzabili e non richiedevano l'esecuzione di un'infrastruttura PKI interna. Tuttavia, presentavano alcune limitazioni:
- Profili di certificato fissi che non possono essere modificati per adattarsi ai casi d'uso interni.
- Audit pubblici e requisiti di conformità imposti dal CA/Browser Forum.
- Nessun controllo sulle finestre di emissione, sui criteri di revoca o sulla politica di ciclo di vita.
- Esposizione alle modifiche delle politiche dei browser e delle piattaforme, come quella in corso.
Al contrario, le autorità di certificazione private offrono alle organizzazioni il controllo completo su emissione, progettazione dei profili, revoca, rinnovo e automazione. Ancora più importante, non sono soggette a vincoli esterni del programma root. Oggi, le moderne soluzioni CA private sono molto più facili da implementare rispetto al passato.
Storicamente, le CA private avevano la reputazione di essere costose, difficili da gestire e lente da implementare. Le organizzazioni dovevano costruire l'infrastruttura PKI da zero, spesso affidandosi a strumenti obsoleti e processi manuali.
Questo non è più vero.
Le moderne CA private, in particolare quelle native per il cloud come Sectigo, possono essere fornite in pochi minuti, scalabili automaticamente e supportano protocolli come ACME, EST e SCEP per una registrazione dei certificati senza interruzioni. Offrono:
- Profili di certificati personalizzabili per una vasta gamma di casi d'uso interni.
- CA private per singolo caso d'uso, se si desidera separare le responsabilità.
- Supporto API completo per l'integrazione in DevOps, MDM e piattaforme di sicurezza.
- Automazione del ciclo di vita e applicazione delle politiche attraverso piattaforme di gestione del ciclo di vita dei certificati (CLM).
Questa evoluzione è così significativa che ha contribuito a innescare il cambiamento di politica di Chrome stesso. Come ha osservato Jason Soroko, Senior Fellow di Sectigo:
“Google si sente autorizzata a farlo perché sa che finalmente disponiamo di opzioni CA private leggere e pronte all'uso. Se fossimo stati 15 anni fa, non avrebbero potuto prendere questa decisione”.
In altre parole, l'infrastruttura CA privata ha finalmente raggiunto l'obiettivo che si era prefissata di raggiungere.
Come il CLM completa il quadro
Passare a una CA privata non significa solo sostituire i certificati, ma anche assumere il controllo della loro gestione.
Con una durata dei certificati SSL/TLS di 47 giorni ormai una realtà, non è più possibile tenere traccia dei certificati con fogli di calcolo o sperare che gli script di rinnovo continuino a funzionare. La visibilità, l'automazione e l'applicazione delle politiche devono essere integrate fin dall'inizio.
È qui che entra in gioco la gestione del ciclo di vita dei certificati (CLM). Una solida piattaforma CLM ti aiuta a:
- Individuare tutti i certificati nel tuo ambiente, pubblico e privato.
- Classificare e contrassegnare i certificati in base al caso d'uso, al sistema e alla scadenza.
- Automatizzare l'emissione, il rinnovo e la revoca su larga scala.
- Applicare le policy relative alla lunghezza della chiave, all'EKU, ai modelli di profilo e altro ancora.
- Evitare interruzioni dovute a certificati scaduti o configurati in modo errato.
- Visualizza tutti i tuoi certificati da un'unica vista unificata, sia privati che pubblici.
Non importa quanto sia valida la tua CA, senza CLM avrai difficoltà a mantenere l'agilità in un panorama digitale in rapida evoluzione.
“Tutte le strade portano al CLM”, come ha affermato Jason. “Ogni certificato avrebbe dovuto essere gestito fin dall'inizio”.
Cosa dovresti fare ora
1. Mappa la tua PKI interna
Iniziate identificando dove viene utilizzata l'autenticazione client TLS nella vostra organizzazione:
- Quali dispositivi, applicazioni o servizi effettuano l'autenticazione con certificati?
- Quali autorità di certificazione li hanno emessi?
- Qualcuno di questi certificati viene emesso tramite flussi di lavoro ACME pubblici (ad esempio Let's Encrypt)?
Se non siete sicuri, Sectigo Certificate Manager può aiutarvi a individuare e inventariare i certificati interni in ambienti cloud, on-premise e ibridi.
2. Valutare i rischi e le tempistiche
Come accennato, tutte le CA pubbliche saranno tenute a eliminare gradualmente il supporto per l'autenticazione client TLS entro maggio 2026. Tutti i certificati che supportano l'autenticazione client emessi da queste fonti dovranno essere sostituiti con certificati emessi da una CA privata.
3. Implementare una CA privata moderna
La soluzione CA privata basata su cloud di Sectigo consente di emettere e gestire certificati per:
- Autenticazione VPN e Wi-Fi
- Identità dei dispositivi e dei carichi di lavoro
- Autenticazione mTLS e API
- Ambienti di sviluppo e pipeline CI/CD
È progettato per una rapida implementazione e scalabilità in tutti gli ambienti. Con il supporto di ACME, EST e SCEP e integrazioni pronte all'uso in Microsoft ADCS e piattaforme di identità cloud, è possibile portare online la PKI privata senza attriti infrastrutturali.
4. Automatizza con la gestione del ciclo di vita dei certificati
Una volta che la tua CA privata è operativa, il passo successivo è garantire completa visibilità e automazione. Sectigo Certificate Manager ti offre:
- Inventario completo di tutti i certificati (pubblici e privati)
- Politiche di emissione basate sui ruoli
- Rinnovo automatico e rotazione
- Avvisi di scadenza e registrazione degli audit
La PKI privata non è più un'opzione
L'eliminazione graduale dell'autenticazione client TLS dalle CA pubbliche non è solo un aggiornamento delle politiche, ma un cambiamento strutturale nel modo in cui deve essere gestita l'autenticazione. Elimina un sostegno su cui molte organizzazioni hanno inconsapevolmente fatto affidamento per anni.
La buona notizia è che la CA privata non è più l'ostacolo di un tempo. E con gli strumenti di gestione dei certificati che stanno recuperando terreno, non c'è mai stato un momento migliore per riprendere il controllo.
Se state ancora condividendo password Wi-Fi o utilizzando certificati client di CA pubbliche per autenticare i laptop, è ora di agire. L'infrastruttura di cui avete bisogno è disponibile e la scadenza è fissata.
Sectigo offre la soluzione di cui la vostra organizzazione ha bisogno per rimanere conforme e agile. Con una CA privata chiavi in mano, la migliore della categoria, indipendente dalla CA e una piattaforma sicura, semplice e scalabile, potete unire i vostri certificati pubblici e privati in uno solo.
