La password è scaduta. La tua rete è pronta per essere sostituita?
La tua organizzazione ha trascorso anni a proteggere l'ingresso principale: firewall, VPN, autenticazione a più fattori, protezione degli endpoint. Ma c'è una domanda più silenziosa a cui molti team IT non hanno ancora risposto completamente: quando un dispositivo, un server o un servizio tenta di dimostrare è chi dice di essereMa cosa supporta concretamente tale affermazione?
Per molte organizzazioni, la risposta onesta è "una password" o "una chiave API". Ed entrambe possono essere rubate, ottenute tramite phishing o riutilizzate da chiunque ne entri in possesso.
Esiste una soluzione migliore, che i browser e i programmi con privilegi di root ormai richiedono di fatto: un certificato di autenticazione client dedicato.
Esplora le opzioni del certificato di autenticazione del client
Perché improvvisamente è diventato urgente
Ecco il cambiamento che ha causato il problema. Dal 15 giugno 2026, il programma Root di Chrome richiede un nuovo certificato rilasciato pubblicamente e attendibile. TLS certificati server per includere solo l'EKU serverAuth. Mozilla, Apple e Microsoft hanno adottato politiche di programma radice compatibili, ponendo fine all'uso degli EKU clientAuth in certificati attendibili pubblicamente. TLS certificati del server.
Se la tua organizzazione stava riutilizzando uno standard TLS certificato per gestire anche l'autenticazione del client o reciproco TLS (mTLS), quella scorciatoia non funziona più. Qualsiasi certificato a doppio scopo che fungeva sia da identità del server che del client non è più valido per l'autenticazione del client e deve essere sostituito con un certificato creato specificamente per tale scopo, come quello fornito da SSL.
Qualsiasi organizzazione che si affida ancora a un vecchio certificato a doppio scopo è già oggi non conforme e il rischio aumenta se il problema non viene risolto. Riguarda chiunque utilizzi l'autenticazione basata su certificati per mTLSAccesso Zero Trust, VPN, accesso alla rete Wi-Fi, dispositivi IoT, sistemi di controllo industriale o piattaforme del mercato energetico.
Che cosa fa effettivamente un certificato di autenticazione client?
Pensa al tuo solito TLS Un certificato di autenticazione funge da badge identificativo per il server. Dimostra che il server è chi dichiara di essere quando il browser si connette ad esso. Un certificato di autenticazione client ribalta la situazione. Consente a un dispositivo, utente, server o servizio di dimostrare la propria identità a qualsiasi entità a cui si connette.
Qui contano i meccanismi, ma solo per le implicazioni che hanno per la tua attività. La chiave privata viene generata direttamente sul dispositivo e non lo abbandona mai. Un'Autorità di Certificazione riconosciuta pubblicamente (come SSL) si limita a firmare la chiave pubblica, associandola a un'identità verificata. Questo significa che non ci sono password memorizzate in qualche database e vulnerabili agli attacchi di phishing, né segreti condivisi che potrebbero essere compromessi in caso di violazione della sicurezza, né chiavi API copiate in script che qualcuno si è dimenticato di aggiornare.
La revoca funziona per singolo certificato, non per l'intera flotta. Se un laptop viene smarrito, l'accesso di un collaboratore esterno termina o un dispositivo viene compromesso, è sufficiente revocare il certificato relativo a quel singolo dispositivo e tutti gli altri endpoint continueranno a funzionare senza interruzioni.
I principali vantaggi, in sintesi
Ecco cosa otterrete concretamente passando a un certificato di autenticazione client dedicato:
- Identità resistente al phishing. La chiave privata non lascia mai il dispositivo, quindi non c'è password da rubare, riutilizzare o tentare di ottenere informazioni tramite phishing.
- Compatibile con Chrome e con i programmi che richiedono i permessi di root. Un EKU clientAuth dedicato che soddisfa i requisiti di CA/Browser Forum e del root store, in modo da non essere colti di sorpresa dal cambiamento di policy che ha dato inizio a tutto questo.
- Gerarchia di cui il pubblico si fida. Emesso dal certificato pubblico WebTrust di SSL PKI, senza la necessità di distribuire una root privata nell'intera infrastruttura del relying party.
- Tre livelli di validazione. IV, OV e IV+OV (Sponsor), in modo che la credenziale sia conforme alla tua politica di identità e a tutti i requisiti normativi a cui sei soggetto.
- Revoca granulare. Revoca un singolo certificato nel momento in cui un dispositivo viene smarrito, dismesso o compromesso, senza intaccare il resto della tua flotta.
- Emissione basata sulle API. Emissione su larga scala oggi tramite l'API REST di SSL, con l'automazione ACME e SCEP/EST in arrivo.
Abbinamento delle credenziali al caso d'uso
La convalida individuale (IV) conferma l'identità reale di una persona specifica, risultando quindi ideale per dispositivi aziendali, politiche BYOD e accesso individuale agli endpoint. La convalida organizzativa (OV) conferma l'esistenza legale di un'azienda, requisito fondamentale per server, macchine virtuali, account di servizio e client API. Per le situazioni in cui sono necessarie entrambe le convalide, come nel caso di utenti privilegiati, collaboratori esterni o settori regolamentati, è disponibile la combinazione IV+OV (convalida dello sponsor), che associa contemporaneamente l'identità di un individuo all'organizzazione sponsor.
Questa flessibilità è importante perché l'autenticazione del client si presenta in molti più punti di quanto la maggior parte delle persone immagini:
|
Usa caso |
Livello di certificazione |
Compatibile con |
Note |
|
mTLS / Zero Trust |
OV / IV+OV |
Nginx, Envoy, Istio, Kong, AWS API Gateway |
Reciproco TLS; entrambi i peer si autenticano con X.509 |
|
VPN (basata su certificati) |
IV / OV / IV+OV |
Cisco ASA/FTD, Palo Alto, Fortinet, Juniper SRX |
Elimina le VPN basate su password; resistente al phishing |
|
Wi-Fi (802.1X / EAP-TLS) |
IV / OV |
Cisco ISE, Aruba ClearPass, Microsoft NPS |
Applicazione del NAC; le credenziali si trovano sul dispositivo, non nella password. |
|
IoT / Identità del dispositivo |
OV |
AWS IoT Core, Azure IoT Hub, broker personalizzati |
Certificazione per dispositivo; revoca individuale senza necessità di riprogrammare l'intera flotta. |
|
OT / SCADA / ICS |
OV |
Claroty, Nozomi, Dragos; pile conformi alla norma IEC 62443 |
Autentica PLC, HMI e nodi di archiviazione dati su reti OT. |
|
Mercati energetici NAESB |
IV+OV |
Piattaforme conformi a NAESB WEQ-12 |
Credenziali richieste per OATI, PowerSecure e altre piattaforme EIS |
|
Autenticazione del gateway API |
OV / IV+OV |
Apigee, Kong, API AWS GW, APIM di Azure |
Sostituisce le chiavi API e i JWT con un'identità di servizio associata a un certificato. |
Oltre a questi casi d'uso specifici, i certificati funzionano ampiamente sull'infrastruttura già in uso dal tuo team:
- TLS pile: OpenSSL, BoringSSL, NSS, SChannel, SecureTransport, wolfSSL e mbedTLS.
- VPN e accesso remoto: Cisco AnyConnect/SecureClient, Palo Alto GlobalProtect, Fortinet FortiClient, OpenVPN e WireGuard (tramite autenticazione esterna).
- NAC e 802.1X: Cisco ISE, Aruba ClearPass, Microsoft NPS/RADIUS, FreeRADIUS e Juniper Access Control.
- Gateway API: Kong, Nginx, Envoy, Istio, AWS API Gateway (mTLS), Azure API Management e Apigee.
- ICS e OT: Piattaforme compatibili con lo standard IEC 62443, inclusi i livelli di rilevamento e autenticazione delle risorse di Claroty, Nozomi Networks e Dragos.
Consegna dei certificati
A prescindere dalle preferenze della tua organizzazione in merito al rilascio dei certificati, SSL offre una soluzione adatta a ogni esigenza:
|
Metodo |
Per chi è |
Come funziona |
|
Interfaccia utente web (pannello di controllo ssl.com) |
Amministratori IT, implementazioni di piccole dimensioni, emissioni una tantum |
Accedi a ssl.com, seleziona Autenticazione client, scegli il livello di convalida, completa la verifica, genera e scarica il certificato. Non è richiesta alcuna conoscenza di programmazione. |
|
API REST |
DevOps, pipeline CI/CD, provisioning di flotte su larga scala |
Ordinazione programmatica dei certificati, CSR Invio e download tramite API REST documentata con SSL. Supporta l'emissione in blocco e l'integrazione con piattaforme di orchestrazione. |
|
ACME / SCEP / EST |
Gestione dei dispositivi mobili aziendali (MDM), automazione conforme allo standard IETF (in programma) |
Automazione del ciclo di vita basata su protocolli tramite ACME (RFC 8555), SCEP ed EST (RFC 7030). In fase di sviluppo: contattare il reparto vendite per informazioni su tempistiche e accesso anticipato. |
Come acquistare
I certificati di autenticazione client sono disponibili direttamente da SSL senza alcun impegno minimo:
- Fai da te. Configura e acquista online.
- Aziendale e di volume. Contatta il team di vendita SSL per prezzi in volume, gestione account dedicata e NAESB-Onboarding specifico.
- Necessità di gerarchia privata o di doppia EKU. Se hai bisogno di una gerarchia privata, di un profilo di certificato personalizzato o di un certificato dual-EKU, SSL privato PKI prodotti (Certificati privati ad alta garanzia, dedicati PKIe Impresa PKI) sono il percorso corretto. Contatta il reparto vendite per un riferimento.
Conclusione
La modifica all'EKU clientAuth non è stata solo una nota a piè di pagina tecnica. È stata una funzione di coercizione che sta spingendo le organizzazioni a separare finalmente l'identità del server da quella del client e a sostituire password e chiavi API con qualcosa che non possa essere oggetto di phishing o replay.
SSL opera da oltre 20 anni come autorità di certificazione pubblica con certificazione WebTrust, e il Certificato di Autenticazione Client rappresenta la soluzione diretta e conforme per qualsiasi organizzazione che necessiti di un'identità client dedicata su larga scala, sia che si tratti di proteggere una rete Zero Trust, una flotta di dispositivi IoT o una piattaforma di trading regolamentata da NAESB.
Se non siete sicuri che la vostra configurazione attuale si basi ancora su un certificato a doppio scopo, è giunto il momento di verificarlo. La data di entrata in vigore è già passata, quindi colmare questa lacuna non è più un'opzione, ma siamo pronti ad aiutarvi.
Il tuo mTLS interessati dalla rimozione dell'EKU clientAuth? Verifica i tuoi certificati per l'EKU clientAuth, quindi parla con SSL della migrazione a certificati di autenticazione client dedicati (o privati) PKI (solo per esigenze interne / doppia EKU) prima della scadenza dei certificati attuali:
