La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento descrive le modifiche dei criteri del programma radice Chrome su Cisco Expressway e autenticazione client EKU tramonto nei certificati CA pubblici dopo 6/26.
I certificati digitali sono credenziali elettroniche rilasciate da Autorità di certificazione (CA) attendibili che proteggono la comunicazione tra server e client garantendo l'autenticazione, l'integrità dei dati e la riservatezza. Questi certificati contengono campi di utilizzo chiavi esteso (EKU, Extended Key Usage) che ne definiscono lo scopo:
In genere, un singolo certificato può contenere sia gli EKU di autenticazione server che quelli di autenticazione client, consentendone il doppio utilizzo. Ciò è particolarmente importante per prodotti come Cisco Expressway che agiscono sia come server che come client in diversi scenari di connessione.

A partire da giugno 2026, i criteri del programma radice Chrome limitano i certificati CA (Certification Authority) radice inclusi nell'archivio radice Chrome, eliminando gradualmente le radici multiuso per allineare tutte le gerarchie di infrastrutture a chiave pubblica (PKI) per servire solo i casi di utilizzo dell'autenticazione del server TLS.
Nota: Questo criterio si applica solo ai certificati rilasciati da CA pubbliche. Questo criterio non influisce sulla PKI privata e sui certificati autofirmati.
In base alla notifica sul campo FN74362, sono interessate tutte le versioni di Cisco Expressway:
|
Prodotto |
Versioni interessate |
Conseguenze |
|
Expressway Core e Edge |
X14 (tutte le versioni) |
Da X14.0.0 a X14.3.7 - Tutte le versioni interessate |
|
Expressway Core e Edge |
X15 (versioni precedenti a X15.4) |
Da X15.0.0 a X15.3.2 - Tutte le versioni interessate |
I prodotti Cisco Expressway (Expressway-C ed Expressway-E) funzionano sia come server che come client in vari scenari di connessione, richiedendo certificati sia con EKU di autenticazione server che client.
Expressway E come server (richiesto EKU di autenticazione server):
Expressway E come client (è richiesto l'utilizzo chiavi avanzato per autenticazione client):
Il certificato pubblico firmato dalla CA con utilizzo chiavi avanzato di autenticazione client attualmente utilizzato per le connessioni mTLS in Cisco Expressway è il certificato server Expressway. Questo certificato viene utilizzato per le seguenti connessioni mTLS:
Avviso FN74362 per campo, prima di prendere in considerazione soluzioni alternative e opzioni:
Gli amministratori possono scegliere una delle seguenti opzioni di soluzione:
Alcune CA radice pubbliche (ad esempio DigiCert e IdenTrust) emettono certificati con EKU combinato da una radice alternativa, che non può essere inclusa nell'archivio di certificati del browser Chrome.
Esempi di CA radice pubbliche e tipi di EKU (per FN74362):
|
Fornitore CA |
Tipo EKU |
CA radice |
Emittente/CA secondaria |
|
AffidabilitàIden |
autenticazione client + autenticazione server |
CA radice settore pubblico IdenTrust 1 |
Server pubblico IdenTrust CA 1 |
|
DigiCert |
autenticazione client + autenticazione server |
DigiCert Assured ID Root G2 |
DigiCert Assured ID CA G2 |
Prerequisiti per questo approccio:
Riferimenti gestione certificati:

I certificati rilasciati dalle CA radice pubbliche prima di maggio 2026 che dispongono di EKU di autenticazione server e client continuano a essere rispettati fino alla scadenza.
Le raccomandazioni generali sono le seguenti:
In base a FN74362, se si utilizzano i certificati Let's Encrypt:

Questa opzione è applicabile a: Solo Expressway C; NON applicabile a Expressway E.
Attenzione: Questa opzione non è disponibile per Expressway-E, che richiede certificati CA pubblici per i servizi esterni e l'attendibilità del browser.
In base alla notifica sul campo FN74362, Cisco sta implementando miglioramenti del prodotto nelle versioni fisse per risolvere completamente questo problema.
Pianificazione rilascio fisso:
|
Prodotto |
Versione interessata |
Versione fissa |
Scopo della correzione |
Disponibilità |
|
Cisco Expressway |
X14.x (tutte le release)<br>X15.x (prima di X15.4) |
X15,4 |
Soluzione intermittente: Consente il caricamento aggiuntivo di un certificato firmato solo dall'EKU di ServerAuth su Expressway E e la regolazione della verifica del certificato per il segnale SIP MRA tra Expressway E ed Expressway C |
Febbraio 2026 |
|
Cisco Expressway |
X14.x (tutte le release)<br>X15.x (prima di X15.5) |
X15.5 |
Soluzione completa: Miglioramento dell'interfaccia utente per la separazione dei certificati client e server e possibilità per gli amministratori di disattivare la verifica EKU |
Maggio 2026 |
Nota: È necessario aggiornare Cisco Expressway E ed Expressway C alla stessa versione.
Scopo: soluzione intermittente per gestire i certificati solo con EKU ServerAuth e abilitare le registrazioni MRA
Miglioramenti principali:
Utenti autorizzati all'aggiornamento a X15.4:
Requisiti importanti per X15.4:
Le limitazioni di X15.4 sono:
Scopo: Soluzione completa per soddisfare i requisiti globali del programma Google Chrome Root
Principali miglioramenti del prodotto:
Nota: In questo caso, anche il peer remoto deve supportare un modello simile di utilizzo chiavi avanzato Ignora autenticazione client

INIZIO: Si utilizzano certificati CA pubblici in Expressway?
Azure
├: PKI privata o autofirmato
│ └ Nessuna azione richiesta - Non influenzata dai criteri
Azure
└ SÌ: Certificati CA pubblici in uso
Azure
├: vengono utilizzati per le connessioni mTLS? (sezione Controllo casi di utilizzo nella sezione Casi di utilizzo specifici interessati)
INSTALLAZIONE
\ ├- NO: Solo autenticazione server
│ ™ · Impatto minimo - Monitoraggio delle modifiche future
INSTALLAZIONE
└ - YES: connessioni mTLS con EKU autenticazione client
INSTALLAZIONE
¨ - Scegliere il proprio approccio:
INSTALLAZIONE
\ ├· Opzione A: Passa a CA radice alternativa
☐ ├. Contattare il provider CA per l'EKU combinato dalla radice alternativa
\ ├- Verificare che tutti i peer siano attendibili
│ ™ Non è necessario alcun aggiornamento software immediato
INSTALLAZIONE
\ ├· Opzione B: Rinnova certificati prima delle scadenze
\ ├· Per crittografare: Rinnovo prima dell'11 febbraio 2026
Monitoraggio attività globale di Azure - Disabilita l'utilità di pianificazione ACME dopo il rinnovo
¨ ├ ™ Per la massima validità: Rinnovo prima del 15 mar 2026
│ ™ ]· Acquista il tempo fino alla scadenza del certificato
INSTALLAZIONE
\ ├· Opzione C: Esegui migrazione a PKI privata (solo Expressway-C)
¨ ├- Impostare l'infrastruttura della CA privata
\ ├· Rilasciare certificati EKU combinati
\ ├- Distribuire la radice a tutti i peer
│ ™ ] Controllo a lungo termine, NOT per Expressway-E
INSTALLAZIONE
└ - Opzione D: Pianificazione dell'aggiornamento software
\ ├- Necessità urgente? → Aggiornamento a X15.4 (Feb 2026)
¨~Soluzione completa → Aggiornamento a X15.5 (maggio 2026)
│ └ Ottenere quindi certificati server/client separati

Q: Devo preoccuparmi di questo se uso la PKI privata?
A: No. Questo criterio ha effetto solo sui certificati rilasciati da CA radice pubbliche. La PKI privata e i certificati autofirmati non sono interessati.
Q: Cosa succede se non si utilizzano le connessioni mTLS?
R: Se si utilizza solo l'autenticazione standard TLS (Server Authentication), questo criterio non influisce sull'utente. I certificati solo server continueranno a funzionare. Verificare tuttavia i casi di utilizzo confrontandoli con l'elenco nella sezione Casi di utilizzo interessati specifici, poiché alcuni casi di utilizzo utilizzano mTLS come impostazione predefinita.
Q: Le connessioni Web HTTPS standard a Expressway smetteranno di funzionare?
R: No. Le connessioni TLS standard non sono interessate. L'accesso del browser Web a Expressway continua a funzionare normalmente anche con i certificati EKU di solo server.
Q: È possibile continuare a utilizzare i certificati esistenti?
A: Sì, i certificati esistenti con utilizzo chiavi avanzato combinato rimangono validi fino alla scadenza. Il problema si verifica quando è necessario eseguire il rinnovo. Funzionano sia per le connessioni TLS che per le connessioni mTLS fino alla scadenza.
Q: Come è possibile stabilire se si sta utilizzando mTLS o TLS standard?
A: Sezione Use Casessection interessata da ReviewSpecific.
D. Cosa posso fare adesso?
R: Cisco consiglia vivamente queste azioni immediate:
Identifica i certificati TLS pubblici utilizzati per mTLS
Rinnovo prima del 15 marzo 2026 per massimizzare la validità
Disabilita rinnovi automatici che possono sostituire certificati in modo imprevisto
Alcune CA offrono profili di certificato temporanei o alternativi
Q: CUCM SU3(a) compatibile con X15.4 e X15.5
A: Sì
Q: È presente una vulnerabilità della sicurezza quando si disabilita il controllo dell'utilizzo chiavi avanzato client in Cisco Expressway E (con versione X15.5)?
R: Il certificato controlla ancora CN/SAN per verificare che l'origine della connessione sia valida, ignora solo la convalida EKU (certificato per lo scopo del ruolo del client) che è stata inclusa per impostazione predefinita finché Google non solleva problemi di sicurezza, pertanto non deve avere problemi di sicurezza rispetto a prima.
Q: Utilizzo Let's Encrypt con ACME su Expressway. Cosa fare?
A:
Q: È possibile modificare il profilo ACME per continuare a ottenere certificati EKU combinati?
A: No. Attualmente Expressway utilizza un profilo ACME "classico" hardcoded che non può essere modificato dagli utenti. Contattare Cisco TAC per il supporto del profilo certificato ACME.
Q: È necessario aggiornare Expressway-E ed Expressway-C?
A: Sì, assolutamente. Per un corretto funzionamento, entrambi devono essere aggiornati alla stessa versione (X15.4 o X15.5).
Q: È possibile eseguire l'aggiornamento a X15.4 o attendere X15.5?
A:
D: La replica del cluster viene interrotta dopo il rinnovo del certificato. Cos'è successo?
R. È molto probabile che il nuovo certificato disponga solo dell'utilizzo chiavi avanzato per l'autenticazione server, ma:
Imposta la modalità di verifica TLS su "Permissiva" (meno sicura)
Ottenere certificati con EKU combinato dalla radice CA alternativa
Eseguire l'aggiornamento a X15.4 o versione successiva, ignorando la verifica dell'utilizzo chiavi avanzato di autenticazione client per ClusterDB
Q: Dopo l'aggiornamento a X15.4, è possibile utilizzare la modalità di imposizione con certificati solo server nel cluster?
R: Sì. A partire da X15.4, Expressway ignora la verifica dell'utilizzo chiavi avanzato autenticazione client per le connessioni mTLS ClusterDB. Pertanto, è possibile impostare la verifica TLS su "Enforcement" anche se uno o più nodi cluster dispongono solo di EKU di autenticazione server.
Q: Perché non è possibile caricare il certificato tramite l'interfaccia utente grafica di Expressway Web?
R: Prima di X15.4, la GUI Web applica una convalida hardcoded che richiede certificati con EKU di autenticazione client. Se il certificato dispone solo dell'utilizzo chiavi avanzato per l'autenticazione server, sono disponibili due opzioni:
Q: Dopo l'aggiornamento a X15.4, non è ancora possibile caricare certificati solo server in Expressway-E
R: Dopo l'aggiornamento, verificare che il comando sia abilitato
CVS certificato XCP TLS xConfiguration EnableServerEkuUpload: On
Q: È stato eseguito l'aggiornamento a X15.4. È ora possibile caricare certificati solo server sia su Expressway-E che su Expressway-C?
R: No. X15.4 rimuove solo la restrizione di caricamento per Expressway-E. Expressway-C richiede ancora certificati EKU combinati per il caricamento tramite GUI Web. Ciò è dovuto al fatto che Expressway-C agisce spesso come client TLS nelle zone di attraversamento UC e richiede l'utilizzo chiavi avanzato di autenticazione client. Assicurarsi di eseguire questo comando in Expressway-E. Questo comando non viene eseguito su Expressway-C
CVS certificato XCP TLS xConfiguration EnableServerEkuUpload: On
Q: Non è possibile registrare la Smart License dopo il rinnovo del certificato. Perché?
A: Errore di Smart Licensing dopo il rinnovo del certificato. In genere NON è correlato all'utilizzo chiavi avanzato:
Q: L'autenticazione a più livelli richiede l'utilizzo chiavi avanzato di autenticazione client su Expressway-E?
R: Dipende dalla versione di Expressway:
Durante la segnalazione SIP MRA, Expressway-E invia il proprio certificato firmato in un messaggio SIP SERVICE a Expressway-C
Expressway-C convalida il certificato, richiedendo sia l'autenticazione client che l'utilizzo chiavi avanzato di autenticazione server
Senza EKU combinato, la registrazione SIP MRA non riesce
Expressway-C non convalida più l'utilizzo chiavi avanzato di autenticazione client nel messaggio SIP SERVICE
Expressway-E richiede solo l'utilizzo chiavi avanzato di autenticazione server per l'Autorità registrazione integrità
La zona trasversale UC funziona in modo unidirezionale (Expressway-C convalida solo il certificato del server Expressway-E)
Q: Errore delle zone adiacenti dopo il caricamento delUtilizzo chiavi avanzato di autenticazione server in Expressway x15.4
A: Se si imposta la modalità di verifica TLS su "on", è necessario che disponga di un EKU di autenticazione client. È quindi possibile disabilitare la verifica TLS nella configurazione della zona adiacente
Q: Quali certificati sono necessari per il corretto funzionamento dell'Autorità registrazione integrità?
A: Per un'implementazione tipica dell'MRA:
|
Componente |
Requisiti dei certificati |
EKU obbligatorio |
Note |
|
Expressway-E (prima di X15.4) |
AutenticazioneServer + AutenticazioneClient |
Entrambi |
Per la convalida SIP SERVICE da Exp-C |
|
Expressway-E (X15.4+) |
solo serverAuth |
Solo server |
Controllo EKU client ignorato |
|
Expressway-C |
autenticazione client + autenticazione server |
Entrambi |
Agisce sempre come client in UC Traversal |
|
Zona trasversale UC |
Convalida unidirezionale |
Exp-E: serverAuth Exp-C: autenticazione client |
Exp-C convalida il certificato del server Exp-E |
Q: Il certificato MRA funziona correttamente, ma dopo il rinnovo del certificato Expressway-E con EKU solo server, la registrazione SIP non riesce. Cosa non funziona?
R: Se si esegue una versione precedente a X15.4, la segnalazione SIP MRA richiede Expressway-E per presentare gli EKU di autenticazione server e client nel messaggio SIP SERVICE. Opzioni:
Q: Come ottenere un certificato con EKU combinato da DigiCert o IdenTrust?
A: Contattare il provider CA e richiedere un certificato dalla radice alternativa che emetta ancora EKU combinato.
Q: La CA indica che è possibile fornire solo certificati di solo server. Cosa fare?
A: Sono disponibili diverse opzioni:
Q: Cosa succede il 15 giugno 2026?
A: Chrome interrompe l'attendibilità dei certificati TLS pubblici contenenti sia gli EKU di autenticazione server che client. I servizi che utilizzano tali certificati possono avere esito negativo.
Q: Perché devo rinnovare prima del 15 marzo 2026?
A: Dopo il 15 marzo 2026, la validità del certificato viene ridotta da 398 a 200 giorni. Il rinnovo prima di questa data offre la durata massima del certificato.
Q: Qual è il termine per l'azione?
A: Esistono più scadenze:

: Supporto di certificati server e client separati per Expressway
Il sunsetting dell'utilizzo chiavi avanzato (EKU) di autenticazione client nei certificati delle CA pubbliche rappresenta un cambiamento significativo nei criteri di sicurezza che influisce sulle distribuzioni Cisco Expressway che utilizzano connessioni mTLS. Sebbene si tratti di una modifica a livello di settore, la valutazione dell'impatto è CRITICA in base alla notifica sul campo FN74362, ed è necessario intervenire immediatamente per evitare interruzioni del servizio.
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
13-Feb-2026
|
Versione iniziale |
Feedback