Riepilogo della gestione
Questo articolo del blog affronta le imminenti modifiche riguardanti la rimozione dell’EKU (Client Authentication Extended Key Usage) dai certificati SSL/TLS pubblicamente attendibili, un cambiamento dettato da preoccupazioni in materia di sicurezza e dalla necessità di ruoli più chiari nelle operazioni crittografiche.
A partire da settembre 2025, le principali autorità di certificazione (CA) inizieranno a eliminare gradualmente l’EKU di autenticazione client dall’emissione di certificati pubblici, con una scadenza definitiva per questa estensione entro la metà del 2026.
L’obiettivo principale di queste modifiche, secondo il forum CA/B, è quello di ridurre la sicurezzarischi associati ai certificati a duplice scopo e imporre linee guida più severe per il loro utilizzo. Le organizzazioni che si affidano a TLS reciproco o all’autenticazione client dovranno adottare certificati client dedicati per garantire la conformità e mantenere operazioni sicure. Questo articolo del blog illustra le implicazioni di queste modifiche, i vantaggi in termini di sicurezza che offrono e le misure concrete che le organizzazioni possono adottare per prepararsi a questa transizione.
Introduzione
Sicurezza e conformità sono considerazioni di primaria importanza per le organizzazioni che utilizzano certificati crittografici per l’autenticazione e la comunicazione. La rimozione dell’Extended Key Usage (EKU) per l’autenticazione client dai certificati SSL ne ridefinirà l’utilizzo, in particolare per gli scenari mutuo TLS (mTLS). Questo articolo del blog fornisce una panoramica completa dell’EKU per l’autenticazione client, delle sue implicazioni e della tempistica per la sua implementazione graduale. Comprendendo questi cambiamenti imminenti, le organizzazioni possono adottare le misure necessarie per garantire la conformità e la sicurezza, migliorando al contempo la chiarezza delle proprie pratiche di gestione dei certificati.
Che cos’è l’EKU (Client Authentication Extended Key Usage)?
L’autenticazione client EKU (Extended Key Usage) è un’estensione del certificato che designa un certificato digitale per l’autenticazione di un client (ad esempio un utente o un dispositivo) su un server, comunemente utilizzato negli scenari mutuo TLS (mTLS).
Si tratta di una funzionalità aggiunta ai certificati digitali che specifica a cosa può essere destinata una chiave pubblica. Crea un elenco chiaro di utilizzi approvati, assicurando che la chiave venga utilizzata solo per determinate attività crittografiche. Gli utilizzi consentiti sono identificati da numeri univoci chiamati Object Identifier (OID), che categorizzano ogni scopo specifico, come la firma del codice, l’autenticazione del server, l’autenticazione del client o la posta elettronica sicura.
Quando qualcuno verifica un certificato, esamina l’EKU per trovare l’OID. Includendo l’estensione EKU, un’Autorità di Certificazione (CA) limita le finalità di utilizzo del certificato, collegando ogni scopo a un OID specifico. Ecco un paio di esempi:
- Autenticazione del server Web TLS: Il certificato può essere utilizzato per verificare un server, ad esempio per un sito web HTTPS. L’OID per l’autenticazione del server è 1.3.6.1.5.5.7.3.1.
- Autenticazione client Web TLS: Il certificato può essere utilizzato da un client per verificare se stesso presso un server, ad esempio nel protocollo TLS reciproco. L’OID per l’autenticazione client è 1.3.6.1.5.5.7.3.2.
Normalmente, browser e server richiedono solo l’EKU serverAuth per impostare una connessione HTTPS sicura. Tuttavia, molti certificati server TLS hanno storicamente incluso sia l’EKU serverAuth che clientAuth.
Utilizzo di EKU in PKI
- Gli EKU limitano i ruoli consentiti di un certificato, come l’autenticazione del server, l’autenticazione del client, la firma del codice o la protezione della posta elettronica.
- Quando è richiesta l’autenticazione del client (ad esempio mTLS), la presenza dell’EKU clientAuth segnala al sistema che il certificato può essere considerato attendibile per tale scopo.
- In passato, alcuni certificati TLS del server includevano sia EKU serverAuth che clientAuth, ma questa pratica è stata abbandonata per ridurre i rischi per la sicurezza e chiarire i ruoli crittografici.
Cambiamenti nel settore
- A partire dal 2025-2026, le principali CA e i programmi root del browser (come Google Chrome) richiederanno la separazione degli EKU di autenticazione server e client, il che significa che i certificati TLS pubblici dovranno avere solo l’EKU serverAuth e non clientAuth, per evitare usi impropri e migliorare la sicurezza.
- Le organizzazioni che necessitano dell’autenticazione client dovranno ora disporre di certificati client dedicati con clientAuth EKU.
Impatto della rimozione dell’EKU di autenticazione client sui certificati SSL
La rimozione dell’EKU di autenticazione client dai certificati SSL implica che i futuri certificati server pubblici saranno utilizzati esclusivamente per l’autenticazione del server e non per scopi lato client come il mutuo TLS (mTLS).
Impatti sull’utilizzo del certificato SSL
- I certificati server emessi dopo la metà del 2025 includeranno solo serverAuth EKU, impedendo qualsiasi utilizzo ambiguo o non sicuro come credenziali di autenticazione client.
- I certificati esistenti (emessi prima delle scadenze) restano validi fino alla scadenza e non saranno revocati retroattivamente.
- I server web HTTPS standard non sono interessati, poiché i browser (come Chrome e Firefox) verificano solo l’autenticazione del server e ignorano l’EKU clientAuth per l’accesso al sito web.
- Per gli ambienti che si basano su mTLS o sull’autenticazione client/dispositivo con certificati SSL pubblici, in futuro sarà richiesto un certificato di autenticazione client separato.
Vantaggi in termini di sicurezza e conformità
- Riduce i rischi di uso improprio e di doppio utilizzo involontario, migliorando la separazione tra la rete Internet pubblica e le infrastrutture PKI interne.
- Allinea tutte le autorità di certificazione (CA) e i browser a linee guida più severe che supportano certificati sicuri e monouso.
Passaggi per le organizzazioni
- Esaminare gli inventari dei certificati per determinare quali sistemi si basano su certificati a doppio uso/server per l’autenticazione client.
- Aggiornare i sistemi per utilizzare certificati client dedicati (con clientAuth EKU) per TLS reciproco, autenticazione del dispositivo o connessioni server-server.
- Modificare i processi/la documentazione di richiesta dei certificati in modo che i rinnovi futuri siano conformi alle nuove policy ed evitino interruzioni del servizio.
Tabella degli effetti
| Caso d’uso |
Cambiamento dopo la rimozione di EKU |
Azione richiesta |
| Siti web HTTPS |
Nessun impatto; lo standard SSL continua |
Nessuno |
| TLS reciproco (mTLS) |
I certificati del server non possono autenticare i client |
Passa ai certificati client dedicati |
| Sistemi legacy/aziendali |
Certificati a duplice uso rifiutati; possibile incompatibilità |
Aggiornare i sistemi, utilizzare certificati client dedicati |
La rimozione dell’autenticazione client EKU è una mossa orientata alla sicurezza per garantire che i certificati SSL vengano utilizzati per gli scopi previsti, con un impatto minimo per la maggior parte degli utenti, ad eccezione di quelli che si affidano ad ambienti di autenticazione mTLS o misti.
Quando le CA smetteranno di rilasciare certificati con Client Authentication EKU?
Le autorità di certificazione (CA) inizieranno a eliminare gradualmente i certificati SSL/TLS con Client Authentication EKU a partire da settembre 2025, con date di scadenza definitive a metà del 2026, a seconda della CA.
Principali punti salienti della cronologia della CA
- 15 settembre 2025:La maggior parte delle principali CA, tra cui Sectigo e Trustico, smetteranno di includere per impostazione predefinita l’EKU di autenticazione client nei nuovi certificati SSL.
- 1 ottobre 2025:DigiCert interromperà per impostazione predefinita l’emissione di certificati TLS pubblici con l’EKU ClientAuth. Eventuali richieste speciali potranno essere soddisfatte fino al 1° maggio 2026, dopodiché nessun certificato pubblico potrà includere l’EKU ClientAuth.
- 13-15 maggio 2026:Scadenze finali per l’intero settore: tutte le principali CA (tra cui Let’s Encrypt, Sectigo, DigiCert e Trustico) rimuoveranno definitivamente Client Authentication EKU dalle nuove emissioni di certificati SSL/TLS pubblici, compresi rinnovi e riemissioni.
- 15 giugno 2026:A partire da questa data, il programma root di Google Chrome considererà attendibili solo i certificati SSL pubblici con serverAuth EKU, rifiutando quelli con ClientAuth EKU.
Tabella riassuntiva
| Nome CA |
Data di arresto predefinita |
Scadenza vincolante |
| Sectigo |
15 settembre 2025 |
15 maggio 2026 |
| DigiCert |
1 ottobre 2025 |
1 maggio 2026 |
| Let’s Encrypt |
Inizio 2026 |
13 maggio 2026 |
| Trustico |
15 settembre 2025 |
15 maggio 2026 |
Dopo queste scadenze, nessun certificato SSL/TLS pubblico nuovo o rinnovato dalle principali CA conterrà l’EKU di autenticazione client, segnando così la transizione a livello di settore.
Quali vantaggi in termini di sicurezza derivano dalla rimozione di ClientAuth EKU?
Secondo il forum CA/B, la rimozione dell’EKU ClientAuth dai certificati SSL pubblicamente attendibili comporta diversi vantaggi chiave in termini di sicurezza, rafforzando la specificità dello scopo del certificato e riducendo i rischi di uso improprio o configurazione errata.
Separazione dei ruoli di fiducia
- I certificati server pubblici verranno utilizzati esclusivamente per l’autenticazione del server e non per l’autenticazione del client o del dispositivo.
- Ciò riduce al minimo la possibilità che i certificati vengano riutilizzati per scopi diversi da quelli previsti, nel rispetto del principio del privilegio minimo.
Rischio ridotto di configurazione errata
- In precedenza, alcuni sistemi accettavano qualsiasi certificato con un EKU ClientAuth per l’autenticazione client, il che comportava un possibile accesso non autorizzato se un certificato del server pubblico veniva erroneamente considerato attendibile.
- Limitando gli EKU agli usi previsti, l’architettura PKI diventa più chiara e più solida per la manutenzione e gli audit.
Miglioramento dell’igiene e della conformità PKI
- L’applicazione di gerarchie di certificati separate per i ruoli server e client allinea le autorità di certificazione (CA) ai requisiti del browser e agli standard PKI moderni.
- Riduce la complessità e la superficie di attacco dei certificati multiuso, semplificando la gestione e la protezione delle distribuzioni PKI pubbliche e private.
Prevenzione dell’abuso dei certificati multiuso
- I certificati ad uso misto (con EKU sia serverAuth che clientAuth) possono essere oggetto di abuso se utilizzati in schemi di autenticazione non previsti, facilitando potenzialmente lo spostamento laterale o l’escalation dei privilegi.
- Richiedendo certificati separati per ogni scopo, le organizzazioni possono monitorare, verificare e controllare meglio gli scenari di accesso sensibili.
Tabella riassuntiva
| Prestazione di sicurezza |
Descrizione |
| Separazione dei ruoli (minimo privilegio) |
Impedisce che i certificati vengano utilizzati al di fuori dell’ambito |
| Riduce il rischio di configurazione errata |
Elimina la sovrapposizione accidentale di EKU client/server |
| Migliora l’architettura PKI |
Consente una chiara separazione PKI e l’applicazione delle policy |
| Abbassa la superficie di attacco |
Non consente l’accesso indesiderato tramite certificati multiuso |
In sintesi, la rimozione di ClientAuth EKU dai certificati SSL del server rafforza la sicurezza chiarendo l’utilizzo dei certificati, rafforzando la conformità e riducendo il rischio che i certificati pubblici vengano utilizzati in modo improprio per scenari di autenticazione client sensibili.
Come preparare i sistemi per la scadenza di EKU?
Per preparare i sistemi alla scadenza dell’EKU di autenticazione client, le organizzazioni devono adottare misure proattive per garantire la continuità delle operazioni sicure e la conformità entro le scadenze del 2025-2026.
Fasi di preparazione
- Inventario dei certificati correnti e utilizzo
- Verificare tutti i certificati SSL/TLS esistenti per identificare quelli che includono l’EKU di autenticazione client.
- Determinare quali applicazionifare affidamento su questi certificati per l’autenticazione del client (ad esempio, TLS reciproco, autenticazione del dispositivo).
- Determinare se e in che modo queste applicazioni che necessitano di un certificato pubblicamente attendibile ServerAuth e ClientAuth supportano effettivamente la configurazione di certificati (e chiavi) ClientAuth e ServerAuth separati. In caso contrario, contattare il fornitore dell’applicazione per verificare se questa funzionalità sarà supportata.
- Pianificare la segmentazione dei certificati
- Separare i ruoli di autenticazione client e server utilizzando certificati dedicati per ogni scopo.
- Ottenere certificati client con ClientAuth EKU esclusivamente per l’autenticazione client e certificati server solo con ServerAuth EKU.
- Aggiornare sistemi e applicazioni
- Modificare il software client e server per supportare certificati distinti per TLS reciproco e altri metodi di autenticazione client.
- Assicurarsi che le applicazioni convalidino correttamente i valori EKU per evitare di accettare certificati non corretti.
- Adattare i processi di gestione dei certificati
- Aggiornare le policy interne e la documentazione per riflettere le nuove restrizioni sull’utilizzo di EKU.
- Coordinarsi con le CA per l’emissione di certificati senza ClientAuth EKU nei certificati del server dopo le scadenze.
- Testare e convalidare
- Eseguire test con modifiche pianificate ai certificati in ambienti di staging o di sviluppo prima del lancio in produzione.
- Verificare che tutti i flussi di autenticazione, incluso il TLS reciproco, funzionino correttamente con le nuove configurazioni dei certificati.
- Comunicare i cambiamenti
- Informare le parti interessate, tra cui IT, team di sicurezza e proprietari delle applicazioni, sull’impatto dell’abbandono di EKU.
- Fornire formazione o indicazioni sulla gestione dei nuovi certificati e sulle pratiche PKI.
Tabella riassuntiva
| Azione |
Descrizione |
| Inventario dei certificati |
Identificare i certificati con ClientAuth EKU |
| Utilizzare certificati dedicati |
Separare i ruoli client e server con EKU pertinenti |
| Aggiornamenti di sistema/applicazione |
Supportare e applicare l’utilizzo di certificati specifici EKU |
| Adeguamento delle politiche/processi |
Riflettere la deprezzamento di EKU nelle politiche di emissione/rinnovo |
| Test e convalida |
Conferma la funzionalità con le nuove impostazioni del certificato |
| Comunicazione con le parti interessate |
Informare i team sulle modifiche e sulla conformità EKU |
Seguendo questa roadmap, le organizzazioni possono ridurre al minimo le interruzioni operative e mantenere una solida strategia di sicurezza PKI durante la transizione alla deprecazione dell’EKU di autenticazione client.
Informazioni specifiche per i clienti KeyTalk
La soluzione di gestione dei certificati e delle chiavi di KeyTalk consente il rinnovo automatico dei certificati (e delle chiavi private) e fornisce i mezzi per inoltrare, installare e configurare automaticamente tali certificati sull’endpoint di destinazione per un’applicazione di destinazione.
Si consiglia ai clienti KeyTalk che necessitano di certificati ClientAuth pubblicamente attendibili di:
- Crea un nuovo modello di certificato dedicato per la richiesta di certificati ClientAuth pubblicamente attendibili. Il modo più semplice è copiare il modello di certificato multiuso esistente e modificarlo in un certificato ClientAuth per la CA pubblica pertinente. Non dimenticare di collegare il nuovo modello di certificato all’autorità di registrazione del database interno.
- Definire manualmente gli FQDN per le applicazioni che necessitano di certificati ClientAuth come KeyTalk SEAT oppure crearli automaticamente in seguito a richieste di nuovi certificati autenticati
- Verifica se l’iscrizione è andata a buon fine e se il tuo KeyTalk CKMS ha ottenuto il tipo corretto di certificato.
- Abilita ACME quando applicabile per il tuo nuovo modello di certificato ClientAuth e annota l’URL univoco del server KeyTalk ACME
- Configurare, ove applicabile, gli agenti ACME esistenti in esecuzione sugli endpoint che ospitano le applicazioni che necessitano del certificato ClientAuth aggiuntivo, per richiedere un certificato aggiuntivo proveniente dall’URL ACME appena abilitato
- Configurare, ove applicabile, gli agenti KeyTalk Enterprise esistenti in esecuzione sugli endpoint che ospitano le applicazioni che necessitano del certificato ClientAuth aggiuntivo, per richiedere un certificato aggiuntivo proveniente dal modello di certificato appena abilitato e, ove necessario, aggiornare gli script Powershell o Bash connessi per applicare correttamente il certificato ClientAuth ottenuto all’applicazione di destinazione.
- Verificare se i certificati ClientAuth automatizzati vengono recuperati correttamente e applicati correttamente alle applicazioni di destinazione.
Hai domande su questo articolo o su come KeyTalk CKMS ti aiuta a semplificare la gestione e l’automazione dei certificati digitali? Il nostro team di supporto è disponibile 24 ore su 24, 7 giorni su 7, per assisterti e guidarti nell’implementazione di un’architettura PKI completamente automatizzata tramite email o la nostra pagina di contatto.
Il team di KeyTalk
