Dal 1° marzo 2027 il mondo dei certificati TLS cambierà per allinearsi a requisiti sempre più stringenti dei browser. DigiCert ha annunciato un percorso di transizione che porterà alla rimozione dell’Extended Key Usage (EKU) “Client Authentication” dai certificati TLS pubblici.
Se oggi usi certificati pubblici solo per HTTPS, potresti non dover fare nulla. Se invece fai mTLS o autenticazione tra sistemi, è il momento giusto per capire cosa succede e quali alternative pianificare.
Cos’è l’EKU
Nei certificati X.509, l’Extended Key Usage (EKU) indica per quali scopi un certificato può essere usato:
- Server Authentication: tipico dei certificati TLS usati per i siti web (HTTPS)
- Client Authentication: serve quando un certificato deve identificare un “client” (persona, dispositivo, applicazione) verso un server, ad esempio in Mutual TLS (mTLS)
Finora, alcuni certificati TLS pubblici potevano includere entrambi gli EKU. Ma i programmi root dei browser spingono verso una separazione più netta degli usi.
Cosa cambia
DigiCert sta eliminando gradualmente l’EKU Client Authentication dai certificati TLS pubblici.
La transizione ha due passaggi fondamentali:
1) Dal 1° ottobre 2025: “Client Authentication” non è più incluso di default
Da quella data, i certificati TLS pubblici vengono emessi di default con il solo EKU Server Authentication.
Se hai bisogno anche del Client Authentication, devi selezionarlo esplicitamente durante la richiesta (o impostare un default a livello di account).
2) Dal 1° marzo 2027: DigiCert non emetterà più certificati pubblici con Client Authentication
A partire da questa data, nei certificati TLS pubblici DigiCert non sarà più possibile includere il Client Authentication EKU, neanche per rinnovi, riemissioni o duplicati.
Nota: i certificati già emessi prima della scadenza continueranno a essere validi fino alla loro naturale scadenza.
Chi è impattato e chi no
Se usi TLS solo per HTTPS (siti web)
Nella maggior parte dei casi, non devi fare nulla: per proteggere un sito web basta l’EKU Server Authentication.
Detto questo, vale la pena fare una verifica interna: a volte certificati “da web” vengono riutilizzati anche per scopi applicativi.
Se usi TLS per mTLS o autenticazione applicativa (server-to-server)
Qui l’impatto può essere concreto. Se il tuo stack (o quello di un partner) si aspetta certificati con Client Authentication, dal 2027 i certificati pubblici non saranno più la strada giusta.
Esempi tipici:
- mutual TLS tra microservizi o tra datacenter
- autenticazione tra un gateway e sistemi terzi
- strong identification di dispositivi/agent/connector
Cosa fare adesso: una checklist pratica
Ecco un percorso “senza panico” ma molto concreto:
1) Mappa gli usi dei certificati
- Dove usiamo TLS?
- Dove usiamo mTLS?
- Quali certificati sono pubblici e quali interni?
2) Identifica i flussi che richiedono Client Authentication
- API B2B con partner
- connessioni application-to-application
- dispositivi/endpoint che presentano un certificato al server
3) Verifica la dipendenza dall’EKU
Non tutti i sistemi validano gli EKU allo stesso modo, ma alcuni lo fanno in modo rigido. Meglio testare prima:
- handshake mTLS in staging
- rotazione certificati simulata
- controllo policy di validazione (reverse proxy, API gateway, Java keystore/truststore, ecc.)
4) Definisci la strategia “post-2027”
In base al caso d’uso, le opzioni tipiche sono:
- PKI privata (Private Trust) per tutto ciò che è interno o controllato dall’organizzazione
- soluzioni “federate”/di settore (es. modelli di trust condiviso) se devi interoperare tra aziende
- gestione dedicata dei certificati “client” separata dai certificati “server”
Alternative: perché una PKI privata diventa la scelta naturale
Per l’autenticazione client, una PKI privata è spesso più adatta dei certificati pubblici, perché:
- non dipende dalle regole dei browser
- puoi definire tu policy, profili EKU, durata, revoca, automazione
- puoi separare chiaramente certificati “server” e “client”
- puoi integrare bene con gestione identità, device management e zero trust
In altre parole: i certificati pubblici restano perfetti per HTTPS, ma per mTLS “serio” e autenticazione macchina-macchina, la direzione è sempre più quella.
Conclusione
La rimozione dell’EKU Client Authentication dai certificati TLS pubblici non è un dettaglio tecnico: è un segnale chiaro di come si sta evolvendo l’ecosistema del Digital Trust.
Se fai solo HTTPS, probabilmente non noterai alcun cambiamento. Se fai mTLS o autenticazione applicativa, invece, conviene:
- censire i casi d’uso
- capire dove serve davvero il Client Authentication
- pianificare una strategia basata su PKI privata o modelli di trust dedicati
Se hai bisogno di aiuto, chiarimenti o maggiori informazioni visita il nostro sito, oppure scrivici a commerciale@trustitalia.it o chiamaci al numero 06 332287 e chiedi di parlare con uno dei nostri commerciali. Il team di Trust Italia sarà pronto e lieto di aiutarti!
Fonte: digicert.com