Risoluzione dei problemi relativi alla verifica dei certificati del server Expressway Traffic per i servizi MRA introdotti da CSCwc69661 / CSCwa25108
Sommario
Introduzione
Questo documento descrive la modifica del comportamento nelle versioni Expressway di X14.2.0 e versioni successive collegata all'ID bug Cisco CSCwc69661 o all'ID bug Cisco CSCwa25108.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Configurazione di base di Expressway
- Configurazione di base MRA
Componenti usati
Le informazioni di questo documento si basano su Cisco Expressway versione X14.2 e successive.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
Con questo cambiamento di comportamento contrassegnato dall'ID bug Cisco CSCwc69661 
o ID bug Cisco CSCwa25108 , il server di traffico sulla piattaforma Expressway esegue la verifica dei certificati dei nodi server Cisco Unified Communications Manager (CUCM), Cisco Unified Instant Messaging & Presence (IM&P) e Unity per i servizi Mobile and Remote Access (MRA). Questa modifica può causare errori di accesso MRA dopo un aggiornamento della piattaforma Expressway.
HTTPS (Hypertext Transfer Protocol Secure) è un protocollo di comunicazione sicuro che utilizza TLS (Transport Layer Security) per crittografare la comunicazione. Questo canale sicuro viene creato mediante l'utilizzo di un certificato TLS scambiato nell'handshake TLS. In questo modo, il server ha due finalità: autenticazione (per sapere a chi si connette la parte remota) e privacy (crittografia). L'autenticazione protegge dagli attacchi man-in-the-middle e la privacy impedisce agli aggressori di intercettare e manomettere la comunicazione.
La verifica TLS (Certificato) viene eseguita con l'obiettivo dell'autenticazione e consente di essere certi di aver effettuato la connessione alla parte remota corretta. La verifica è costituita da due elementi distinti:
1. Catena di Autorità di certificazione (CA) attendibili
2. Nome alternativo del soggetto (SAN) o nome comune (CN)
Catena CA attendibile
Affinché Expressway-C consideri attendibile il certificato inviato da CUCM / IM&P / Unity, è necessario che sia in grado di stabilire un collegamento da tale certificato a un'Autorità di certificazione (CA) di livello superiore (principale) considerata attendibile. Tale collegamento, ovvero una gerarchia di certificati che collega un certificato di entità a un certificato CA radice, è denominato catena di attendibilità. Per poter verificare tale catena di attendibilità, ogni certificato contiene due campi: Emittente (o 'Rilasciato da') e Oggetto (o 'Rilasciato a').
I certificati server, ad esempio quello inviato da CUCM a Expressway-C, hanno in genere nel campo 'Oggetto' il nome di dominio completo (FQDN) della CN:
Issuer: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
Subject: C=BE, ST=Flamish-Brabant, L=Diegem, O=Cisco, OU=TAC, CN=cucm.vngtp.lab
Esempio di certificato server per CUCM.vngtp.lab. Il nome di dominio completo (FQDN) è presente nell'attributo CN del campo Oggetto insieme ad altri attributi, quali Paese (C), Stato (ST), Posizione (L), ... Si noti inoltre che il certificato del server viene rilasciato da una CA denominata vngtp-ACTIVE-DIR-CA.
Le CA di livello superiore (CA radice) possono inoltre rilasciare un certificato per identificarsi. In questo certificato CA radice, è possibile notare che l'autorità emittente e l'oggetto hanno lo stesso valore:
Issuer: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
Subject: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
Si tratta di un certificato rilasciato da una CA radice per identificarsi.
In una situazione tipica, le CA radice non rilasciano direttamente certificati server. Al contrario, emettono certificati per altre CA. Tali altre CA vengono quindi definite CA intermedie. Le CA intermedie possono a loro volta emettere direttamente certificati server o certificati per altre CA intermedie. Si può verificare una situazione in cui un certificato server viene rilasciato dalla CA intermedia 1, che a sua volta ottiene un certificato dalla CA intermedia 2 e così via. Finché la CA intermedia non ottiene il proprio certificato direttamente dalla CA radice:
Server certificate :
Issuer: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-1 Subject: C=BE, ST=Flamish-Brabant, L=Diegem, O=Cisco, OU=TAC, CN=cucm.vngtp.lab
Intermediate CA 1 certificate :
Issuer: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-2
Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-1
Intermediate CA 2 certificate :
Issuer: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-3
Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-2
...
Intermediate CA n certificate :
Issuer: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-n
Root CA certificate :
Issuer: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
Subject: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-C
Ora, affinché Expressway-C consideri attendibile il certificato server inviato da CUCM, è necessario che sia in grado di creare la catena di attendibilità da tale certificato server fino a ottenere un certificato CA radice. A tale scopo, è necessario caricare il certificato CA radice e tutti i certificati CA intermedi (se presenti, il che non è il caso se la CA radice avrebbe rilasciato direttamente il certificato server di CUCM) nell'archivio di attendibilità di Expressway-C.
Controllo SAN o CN
Il passaggio 1 consente di estrarre l'archivio di attendibilità. In questo caso, tuttavia, chiunque disponga di un certificato firmato da una CA nell'archivio di attendibilità sarà valido. Questo chiaramente non è sufficiente. Pertanto, è disponibile un ulteriore controllo che consente di verificare che il server a cui ci si connette sia effettivamente quello corretto. L'indirizzo a cui si riferisce la richiesta è quello indicato nella richiesta.
Lo stesso tipo di operazione si verifica nel browser, quindi esaminiamo questo aspetto attraverso un esempio. Se si passa a https://www.cisco.com, accanto all'URL immesso viene visualizzata un'icona a forma di lucchetto che indica che la connessione è attendibile. Questo si basa sia sulla catena di attendibilità della CA (dalla prima sezione) sia sul controllo della SAN o della CN. Se si apre il certificato (tramite il browser facendo clic sull'icona a forma di lucchetto), si noterà che il campo Nome comune (visualizzato nel campo 'Rilasciato a:') è impostato su www.cisco.com e corrisponde esattamente all'indirizzo a cui si desidera connettersi. In questo modo, è possibile essere certi di connettersi al server corretto, in quanto la CA che ha firmato il certificato e che esegue la verifica prima della distribuzione del certificato è considerata attendibile.
Quando si esaminano i dettagli del certificato e in particolare le voci SAN, si osserva che lo stesso vale per altri FQDN:
Ciò significa che quando si richiede la connessione a https://www1.cisco.com, ad esempio, questa viene visualizzata anche come connessione protetta, in quanto è inclusa nelle voci SAN.
Tuttavia, se si sceglie https://www.cisco.com ma si accede direttamente all'indirizzo IP (https://72.163.4.161), la connessione non risulterà sicura in quanto l'autorità di certificazione che l'ha firmata non è considerata attendibile, ma il certificato presentato non contiene l'indirizzo (72.163.4.161) utilizzato per la connessione al server.
Nel browser è possibile ignorare questa impostazione, ma è possibile abilitarla sulle connessioni TLS in modo che non sia consentito ignorarla. È pertanto importante che i certificati contengano i nomi CN o SAN corretti che la parte remota intende utilizzare per connettersi.
Modifica del comportamento
I servizi MRA si basano molto su diverse connessioni HTTPS su Expressways verso i server CUCM / IM&P / Unity per autenticarsi correttamente e raccogliere le informazioni appropriate specifiche per il client che esegue il login. Questa comunicazione in genere ha luogo sulle porte 8443 e 6972.
Versioni inferiori a X14.2.0
Nelle versioni precedenti a X14.2.0, il server di traffico su Expressway-C che gestisce queste connessioni HTTPS sicure non ha verificato il certificato presentato dall'estremità remota. Questo potrebbe portare ad attacchi di tipo man-in-the-middle. Nella configurazione MRA è disponibile un'opzione per la verifica del certificato TLS mediante la configurazione di 'Modalità verifica TLS' su 'Attivata' quando si aggiungono server CUCM / IM&P / Unity in Configurazione > Comunicazioni unificate > Server CM unificati / Nodi IM e Servizio presenza / Server Unity Connection. L'opzione di configurazione e la casella delle informazioni rilevanti vengono mostrate come esempio, a indicare che non verifica l'FQDN o l'IP nella SAN, nonché la validità del certificato e se è firmato da una CA attendibile.
Questo controllo di verifica del certificato TLS viene eseguito solo al rilevamento dei server CUCM/IM&P/Unity e non al momento dell'accesso MRA ai vari server. Un primo inconveniente di questa configurazione è che la verifica solo per l'indirizzo dell'autore aggiunto. Non verifica se il certificato nei nodi del sottoscrittore è stato impostato correttamente in quanto recupera le informazioni sul nodo del sottoscrittore (FQDN o IP) dal database del nodo del server di pubblicazione. Un secondo inconveniente di questa configurazione è che ciò che viene annunciato ai client MRA come informazioni di connessione può essere diverso dall'indirizzo dell'autore che è stato messo nella configurazione Expressway-C. Ad esempio su CUCM, in Sistema > Server è possibile annunciare il server all'esterno con un indirizzo IP (ad esempio 10.48.36.215) e questo viene poi utilizzato dai client MRA (tramite la connessione Expressway proxy), tuttavia è possibile aggiungere il CUCM su Expressway-C con il FQDN di cucm.steven.lab. Si supponga quindi che il certificato tomcat di CUCM contenga cucm.steven.lab come voce SAN ma non l'indirizzo IP. La ricerca con 'Modalità di verifica TLS' impostata su 'Attivata' avrà esito positivo, ma le comunicazioni effettive provenienti dai client MRA possono avere come destinazione un FQDN o un IP diverso e pertanto non superano la verifica TLS.
Versioni di X14.2.0 e successive
A partire dalla versione X14.2.0, il server Expressway esegue la verifica del certificato TLS per ogni singola richiesta HTTPS effettuata tramite il server di traffico. Ciò significa che questa operazione viene eseguita anche quando 'TLS Verify Mode' è impostato su 'Off' durante il rilevamento dei nodi CUCM / IM&P / Unity. Se la verifica non ha esito positivo, l'handshake TLS non viene completato e la richiesta non riesce. Ciò può causare, ad esempio, la perdita di funzionalità quali problemi di ridondanza o failover o errori di accesso completi. Inoltre, se 'TLS Verify Mode' è impostata su 'On', non è possibile garantire che tutte le connessioni funzionino correttamente, come illustrato nell'esempio riportato di seguito.
I certificati esatti che Expressway controlla verso i nodi CUCM / IM&P / Unity sono come mostrato nella sezione della guida MRA.
Oltre all'impostazione predefinita per la verifica TLS, esiste anche una modifica introdotta in X14.2 che potrebbe annunciare un ordine di preferenza diverso per l'elenco di cifratura, che dipende dal percorso di aggiornamento. Ciò può causare connessioni TLS impreviste dopo un aggiornamento software, perché può accadere che prima dell'aggiornamento richiesto per il certificato Cisco Tomcat o Cisco CallManager da CUCM (o qualsiasi altro prodotto che abbia un certificato separato per l'algoritmo ECDSA) ma che dopo l'aggiornamento richieda per la variante ECDSA (che è la variante di cifratura più sicura in realtà di RSA). È possibile che i certificati Cisco Tomcat-ECDSA o Cisco CallManager-ECDSA siano firmati da un'autorità di certificazione diversa o semplicemente autofirmati (impostazione predefinita).
La modifica dell'ordine delle preferenze di cifratura non è sempre rilevante in quanto dipende dal percorso di aggiornamento, come illustrato nelle note di rilascio di Expressway X14.2.1. In breve, è possibile vedere da Manutenzione > Sicurezza > Cifre per ciascuno dei cifrari se è preceduto o meno "ECDHE-RSA-AES256-GCM-SHA384:". In caso contrario, preferisce la cifratura ECDSA più recente a quella RSA. In caso affermativo, si avrà il comportamento precedente di RSA che ha la preferenza più alta.
La verifica TLS potrebbe non riuscire in questo scenario in due modi, descritti in dettaglio più avanti:
1. La CA che ha firmato il certificato remoto non è attendibile
a. Certificato autofirmato
b. Certificato firmato da una CA sconosciuta
2. L'indirizzo di connessione (FQDN o IP) non è contenuto nel certificato
Risoluzione dei problemi
Gli scenari successivi mostrano uno scenario simile in un ambiente lab in cui l'accesso MRA non è riuscito dopo un aggiornamento di Expressway da X14.0.7 a X14.2. Condividono analogie nei registri, ma la risoluzione è diversa. I registri vengono raccolti dalla registrazione diagnostica (da Manutenzione > Diagnostica > Registrazione diagnostica) avviata prima dell'accesso all'MRA e interrotta dopo che l'accesso all'MRA non è riuscito. Non è stata abilitata alcuna registrazione di debug aggiuntiva.
1. La CA Che Ha Firmato Il Certificato Remoto Non È Attendibile
Il certificato remoto potrebbe essere firmato da una CA non inclusa nell'archivio di attendibilità di Expressway-C oppure potrebbe essere un certificato autofirmato (in sostanza anche una CA) che non viene aggiunto nell'archivio di attendibilità del server Expressway-C.
Nell'esempio riportato di seguito, è possibile osservare che le richieste inviate a CUCM (10.48.36.215 - cucm.steven.lab) vengono gestite correttamente sulla porta 8443 (risposta 200 OK) ma genera un errore (risposta 502) sulla porta 6972 per la connessione TFTP.
===Success connection on 8443===
2022-07-11T18:55:25.910+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,910" Module="network.http.trafficserver" Level="INFO": Detail="Receive Request" Txn-id="189" TrackingID="6af9a674-9ebc-41ea-868e-90e7309a758c" Src-ip="127.0.0.1" Src-port="35764" Last-via-addr="" Msg="GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy9jdWNtLnN0ZXZlbi5sYWIvODQ0Mw/cucm-uds/user/emusk/devices HTTP/1.1"
2022-07-11T18:55:25.917+02:00 vcsc traffic_server[18242]: Event="Request Allowed" Detail="Access allowed" Reason="In allow list" Username="emusk" Deployment="1" Method="GET" Request="https://cucm.steven.lab:8443/cucm-uds/user/emusk/devices" Rule="https://cucm.steven.lab:8443/cucm-uds/user/" Match="prefix" Type="Automatically generated rule for CUCM server" UTCTime="2022-07-11 16:55:25,916"
2022-07-11T18:55:25.917+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,916" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="189" TrackingID="6af9a674-9ebc-41ea-868e-90e7309a758c" Dst-ip="10.48.36.215" Dst-port="8443" Msg="GET /cucm-uds/user/emusk/devices HTTP/1.1"
2022-07-11T18:55:25.955+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,955" Module="network.http.trafficserver" Level="INFO": Detail="Receive Response" Txn-id="189" TrackingID="" Src-ip="10.48.36.215" Src-port="8443" Msg="HTTP/1.1 200 "
2022-07-11T18:55:25.956+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,955" Module="network.http.trafficserver" Level="INFO": Detail="Sending Response" Txn-id="189" TrackingID="" Dst-ip="127.0.0.1" Dst-port="35764" Msg="HTTP/1.1 200 "
===Failed connection on 6972===
2022-07-11T18:55:26.000+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,000" Module="network.http.trafficserver" Level="INFO": Detail="Receive Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Src-ip="127.0.0.1" Src-port="35766" Last-via-addr="" Msg="GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy9jdWNtLnN0ZXZlbi5sYWIvNjk3Mg/CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.006+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,006" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Dst-ip="10.48.36.215" Dst-port="6972" Msg="GET /CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,016" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Dst-ip="10.48.36.215" Dst-port="6972" Msg="GET /CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: [ET_NET 0] WARNING: Core server certificate verification failed for (cucm.steven.lab). Action=Terminate Error=self signed certificate server=cucm.steven.lab(10.48.36.215) depth=0
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: [ET_NET 0] ERROR: SSL connection failed for 'cucm.steven.lab': error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2022-07-11T18:55:26.024+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,024" Module="network.http.trafficserver" Level="INFO": Detail="Sending Response" Txn-id="191" TrackingID="" Dst-ip="127.0.0.1" Dst-port="35766" Msg="HTTP/1.1 502 connect failed"
L'errore di 'verifica certificato non riuscita' indica che Expressway-C non è stato in grado di convalidare l'handshake TLS. Il motivo è indicato nella riga di avviso in quanto indica un certificato autofirmato. Se la profondità è indicata da 0, si tratta di un certificato autofirmato. Quando la profondità è maggiore di 0, significa che dispone di una catena di certificati e pertanto è firmata da un'autorità di certificazione sconosciuta (dal punto di vista di Expressway-C).
Quando si controlla il file pcap che è stato raccolto in corrispondenza dei timestamp indicati dai log di testo, si può notare che CUCM presenta il certificato con CN come cucm-ms.steven.lab (e cucm.steven.lab come SAN) firmato da steven-DC-CA per Expressway-C sulla porta 8443.
Ma quando ispezioniamo il certificato presentato sulla porta 6972, possiamo vedere che è un certificato autofirmato (l'emittente è se stesso) con CN impostato come cucm-EC.steven.lab. L'estensione -EC fornisce l'indicazione che si tratta del certificato ECDSA installato su CUCM.
In CUCM, in Amministrazione del sistema operativo unificato Cisco, è possibile esaminare i certificati in uso in Protezione > Gestione certificati, come mostrato ad esempio qui. Viene visualizzato un certificato diverso per tomcat e tomcat-ECDSA in cui il tomcat è firmato dall'autorità di certificazione (e considerato attendibile da Expressway-C) mentre il certificato tomcat-ECDSA è autofirmato e non considerato attendibile da Expressway-C.
2. L'indirizzo di connessione (FQDN o IP) non è contenuto nel certificato
Oltre all'archivio di attendibilità, il server del traffico verifica anche l'indirizzo di connessione verso cui il client di Autorità registrazione integrità effettua la richiesta. Ad esempio, se avete impostato su CUCM in Sistema > Server il vostro CUCM con l'indirizzo IP (10.48.36.215), Expressway-C lo annuncia come tale al client e le richieste successive dal client (proxy attraverso Expressway-C) sono destinate a questo indirizzo.
Quando l'indirizzo di connessione non è contenuto nel certificato del server, anche la verifica TLS ha esito negativo e viene generato un errore 502 che, ad esempio, genera un errore di accesso MRA.
2022-07-11T19:49:01.472+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,472" Module="network.http.trafficserver" Level="DEBUG": Detail="Receive Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Src-ip="127.0.0.1" Src-port="30044" Last-via-addr=""
HTTPMSG:
|GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy8xMC40OC4zNi4yMTUvODQ0Mw/cucm-uds/user/emusk/devices?max=100 HTTP/1.1
...
2022-07-11T19:49:01.478+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,478" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Dst-ip="10.48.36.215" Dst-port="8443" Msg="GET /cucm-uds/user/emusk/devices?max=100 HTTP/1.1"
2022-07-11T19:49:01.478+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,478" Module="network.http.trafficserver" Level="DEBUG": Detail="Sending Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Dst-ip="10.48.36.215" Dst-port="8443"
HTTPMSG:
|GET /cucm-uds/user/emusk/devices?max=100 HTTP/1.1
...
2022-07-11T19:49:01.491+02:00 vcsc traffic_server[3916]: [ET_NET 2] WARNING: SNI (10.48.36.215) not in certificate. Action=Terminate server=10.48.36.215(10.48.36.215)
2022-07-11T19:49:01.491+02:00 vcsc traffic_server[3916]: [ET_NET 2] ERROR: SSL connection failed for '10.48.36.215': error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Dove c3RldmVuLmxhYi9odHRwcy8xMC40OC4zNi4yMTUvODQ0Mw traduce (base64 - https://www.base64decode.org/) in steven.lab/https/10.48.36.215/8443, che indica che è necessario impostare la connessione a 10.48.36.215 come indirizzo di connessione anziché a cucm.steven.lab. Come mostrato nelle acquisizioni del pacchetto, il certificato tomcat CUCM non contiene l'indirizzo IP nella SAN e quindi viene generato l'errore.
Come convalidarlo in modo semplice
È possibile verificare se il comportamento cambia facilmente con i passaggi successivi:
1. Avviare la registrazione diagnostica sui server Expressway-E e C (idealmente con TCPDump abilitato) da Manutenzione > Diagnostica > Registrazione diagnostica (nel caso di un cluster, è sufficiente avviarlo dal nodo primario)
2. Tentare un accesso MRA o testare la funzionalità interrotta dopo l'aggiornamento
3. Attendere che si verifichi un errore e quindi arrestare la registrazione diagnostica sui server Expressway-E e C (nel caso di un cluster, assicurarsi di raccogliere i log da ogni singolo nodo del cluster)
4. Caricare e analizzare i log nello strumento Collaboration Solution Analyzer
5. Se si verifica il problema, vengono selezionate le righe di avvertenza e di errore più recenti relative alla modifica per ognuno dei server interessati
Firma diagnostica CA
Firma diagnostica SNI
Soluzione
La soluzione a lungo termine consiste nel garantire che la verifica TLS funzioni correttamente. L'azione da eseguire dipende dal messaggio di avviso visualizzato.
Quando viene visualizzato il messaggio di AVVISO: verifica del certificato del server di base non riuscita per (<server-FQDN-or-IP>). Action=Terminate Error=self-signed certificate server=cucm.steven.lab(10.48.36.215) depth=x message, quindi è necessario aggiornare l'archivio di attendibilità sui server Expressway-C di conseguenza. Con la catena di CA che ha firmato il certificato (profondità > 0) o con il certificato autofirmato (profondità = 0) da Manutenzione > Sicurezza > Certificato CA attendibile. Accertarsi di eseguire questa azione su ogni server del cluster. In alternativa, è possibile firmare il certificato remoto da una CA nota nell'archivio di attendibilità di Expressway-C.
Quando si osserva il messaggio WARNING: SNI (<server-FQDN-or-IP>) not in certificate (AVVISO: SNI (<server-FQDN-or-IP>) not in certificate (AVVISO: SNI (<server-FQDN-or-IP>) not in certificate (AVVISO: SNI) not in certificate (messaggio di avviso: SNI) indica che questo FQDN o IP del server non è contenuto nel certificato presentato. È possibile adattare il certificato in modo da includere tali informazioni oppure modificare la configurazione (ad esempio in CUCM su Sistema > Server in base a quanto contenuto nel certificato del server) e quindi aggiornare la configurazione sul server Expressway-C in modo da tenerne conto.
La soluzione a breve termine consiste nell'applicare la soluzione descritta nella documentazione per ripristinare il comportamento precedente a X14.2.0. È possibile eseguire questa operazione tramite la CLI sui nodi del server Expressway-C con il comando appena introdotto:
xConfiguration EdgeConfigServer VerifyOriginServer: OffCronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
4.0 |
17-Oct-2022 |
L'aggiornamento dell'elenco di cifratura dipende dal percorso di aggiornamento in CSCwc88608 |
3.0 |
21-Sep-2022 |
X14.0.9 non è influenzato da questa modifica |
2.0 |
15-Sep-2022 |
Applicabile anche a partire da X14.0.9 poiché è stato eseguito il backporting della modifica |
1.0 |
02-Aug-2022 |
Versione iniziale |
Feedback