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).
In questo documento viene descritto come configurare Cisco Unified Contact Center Express (UCCX) per l'utilizzo di certificati autofirmati e firmati.
Prima di procedere con le operazioni di configurazione descritte in questo documento, assicurarsi di avere accesso alla pagina Amministrazione del sistema operativo (OS) per le seguenti applicazioni:
Un amministratore può inoltre accedere all'archivio certificati nei PC client dell'agente e del supervisore.
È necessario che tutti i server nella configurazione UCCX siano installati con i server DNS (Domain Name System) e i nomi di dominio. È inoltre necessario che agenti, supervisori e amministratori accedano alle applicazioni di configurazione UCCX tramite il nome di dominio completo (FQDN).
Se il dominio viene modificato o popolato per la prima volta, i certificati possono essere rigenerati. Dopo aver aggiunto il nome di dominio alla configurazione del server, rigenerare tutti i certificati Tomcat prima di installarli nelle altre applicazioni, nei browser client o al momento della generazione della richiesta di firma del certificato (CSR) per la firma.
Le informazioni descritte in questo documento si basano sui seguenti componenti hardware e software:
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.
Con l'introduzione del coresidente Finesse e CUIC, l'integrazione tra UCCX e SocialMiner per la posta elettronica e la chat e l'utilizzo di MediaSense per registrare, comprendere e installare certificati tramite Finesse, la capacità di risolvere i problemi relativi ai certificati è ora di fondamentale importanza.
In questo documento viene descritto l'utilizzo di certificati autofirmati e firmati nell'ambiente di configurazione UCCX per:
I certificati, firmati o autofirmati, devono essere installati sia sulle applicazioni (server) nella configurazione UCCX, sia sui desktop dell'agente e del supervisore del client.
Il supporto multi-SAN è stato aggiunto in UCCX a partire dalla versione 11.6.2.
Pubblicamente, i certificati CA firmati su SomicalMiner/CCP sono necessari per il funzionamento della chat esterna su Internet.
In questa sezione viene descritto come configurare UCCX per l'utilizzo di certificati autofirmati e firmati.
Il metodo consigliato per la gestione dei certificati per la configurazione UCCX consiste nell'utilizzare certificati firmati. Questi certificati possono essere firmati da un'Autorità di certificazione (CA) interna o da un'Autorità di certificazione (CA) di terze parti.
Nei principali browser, ad esempio Mozilla Firefox e Microsoft Edge, per impostazione predefinita vengono installati i certificati radice per le CA di terze parti conosciute. I certificati per le applicazioni di configurazione UCCX firmati da queste CA sono attendibili per impostazione predefinita, in quanto la catena di certificati termina con un certificato radice già installato nel browser.
Il certificato radice di una CA interna può inoltre essere preinstallato nel browser client tramite Criteri di gruppo o altre configurazioni correnti.
È possibile scegliere se i certificati dell'applicazione di configurazione UCCX devono essere firmati da un'autorità di certificazione di terze parti nota oppure da un'autorità di certificazione interna in base alla disponibilità e alla preinstallazione del certificato radice per le autorità di certificazione nel browser client.
Completare i seguenti passaggi per ogni nodo delle applicazioni UCCX Publisher and Subscriber, SocialMiner, e MediaSense Publisher and Subscriber Administration:
Inviare il nuovo CSR alla CA di terze parti o firmarlo con una CA interna, come descritto in precedenza. Questo processo può produrre i certificati firmati seguenti:
Nota: lasciare il campo Distribuzione nel CSR come nome di dominio completo del server.
Nota: il certificato SAN (Multi-Server) è supportato per UCCX a partire dalla versione 11.6. Tuttavia, la SAN può includere solo UCCX Node-1 e Node-2. Altri server, ad esempio SocialMiner, non possono essere inclusi nella SAN di UCCX. Vedere in fondo alla pagina per un esempio di SAN CUCM valido anche per UCCX.
Nota: UCCX supporta solo lunghezze delle chiavi dei certificati di 1024 e 2048 bit.
Completare la procedura seguente in ogni server applicazioni per caricare il certificato radice e il certificato dell'applicazione nei nodi:
Nota: se si caricano i certificati radice e intermedi in un server di pubblicazione (UCCX o MediaSense), è possibile replicarli automaticamente nel Sottoscrittore. Non è necessario caricare i certificati radice o intermedi negli altri server non publisher della configurazione se tutti i certificati delle applicazioni sono firmati tramite la stessa catena di certificati.
Nota: se una CA subordinata firma il certificato, caricare il certificato radice della CA subordinata come certificato tomcat-trust anziché come certificato radice. Se viene rilasciato un certificato intermedio, oltre al certificato dell'applicazione caricare il certificato nell'archivio Tomcat-trust.
Nota: quando si utilizza UCCX e SocialMiner 11.5, è disponibile un nuovo certificato denominato tomcat-ECDSA. Quando si carica un certificato tomcat-ECDSA firmato nel server, caricare il certificato dell'applicazione come certificato tomcat-ECDSA e non come certificato tomcat. Per ulteriori informazioni su ECDSA, fare riferimento alla sezione Informazioni correlate per il collegamento che consente di comprendere e configurare i certificati ECDSA. A partire dalla versione 11.6, l'utilizzo dei certificati ECDSA è stato completamente rimosso dalla soluzione UCCX. Ciò include UCCX, SM/CCP, CUIC e Finesse.
Tutti i certificati utilizzati nella configurazione UCCX sono preinstallati nelle applicazioni di configurazione e autofirmati. Questi certificati autofirmati non sono implicitamente attendibili quando vengono presentati a un browser client o a un'altra applicazione di configurazione. Sebbene sia consigliabile firmare tutti i certificati nella configurazione UCCX, è possibile utilizzare i certificati autofirmati preinstallati.
Per ogni relazione tra applicazioni, è necessario scaricare il certificato appropriato e caricarlo nell'applicazione. Per ottenere e caricare i certificati, completare i seguenti passaggi:
Per installare certificati autofirmati nel computer client, utilizzare Criteri di gruppo o Gestione pacchetti oppure installarli singolarmente nel browser di ogni PC agente.
Per Microsoft Edge, installare i certificati autofirmati lato client nell'archivio Autorità di certificazione radice attendibili.
Per Mozilla Firefox, completare questi passaggi:
Nel caso in cui i certificati autofirmati scadano, è necessario rigenerarli e ripetere le operazioni di configurazione dell'installazione sui server periferici.
UCCX utilizza le API REST e di notifica di SocialMiner per gestire i contatti e la configurazione della posta elettronica. Entrambi i nodi UCCX devono utilizzare l'API REST di SocialMiner ed essere notificati dal servizio di notifica SocialMiner, quindi installare il certificato SocialMiner Tomcat su entrambi i nodi UCCX.
Caricare la catena di certificati firmati o autofirmati del server SocialMiner nel keystore UCCX tomcat-trust.
Caricare il certificato UCCX tomcat dai nodi del server di pubblicazione e del Sottoscrittore nel server SocialMiner come keystore tomcat-trust.
Il certificato client UCCX AppAdmin viene utilizzato per l'amministrazione del sistema UCCX. Per installare il certificato UCCX AppAdmin per gli amministratori UCCX, nel PC client passare a https://<UCCX FQDN>/appadmin/main per ogni nodo UCCX e installare il certificato tramite il browser.
I servizi Web UCCX vengono utilizzati per la consegna di contatti di chat ai browser client. Per installare il certificato della piattaforma UCCX per gli agenti e i supervisori UCCX, nel PC client passare a https://<UCCX FQDN>/appadmin/main per ciascuno dei nodi UCCX e installare il certificato tramite il browser.
Il servizio di notifica CCX viene utilizzato da Finesse, UCCX e CUIC per inviare informazioni in tempo reale al desktop del client tramite il protocollo XMPP (Extensible Messaging and Presence Protocol). È utilizzato per la comunicazione Finesse in tempo reale e per CUIC Live Data.
Per installare il certificato client del Servizio di notifica sul PC degli agenti e dei supervisori o degli utenti per i rapporti che utilizzano Live Data, passare a https://<FQDN UCCX>:7443/ per ciascuno dei nodi UCCX e installare il certificato tramite il browser.
Il certificato client Finesse viene utilizzato dai desktop Finesse per connettersi all'istanza Finesse Tomcat ai fini della comunicazione API REST tra il desktop e il server Finesse coresidente.
Per installare il certificato Finesse per agenti e supervisori, nel PC client passare a https://<UCCX FQDN>:8445/8445 per ciascuno dei nodi UCCX e installare il certificato tramite le richieste del browser.
Per installare il certificato Finesse per gli amministratori Finesse, nel PC client passare a https://<UCCX FQDN>:8445/cfadmin per ciascuno dei nodi UCCX e installare il certificato tramite le richieste del browser.
Il certificato Tomcat di SocialMiner deve essere installato nel computer client. Quando un agente accetta una richiesta di chat, il gadget Chat viene reindirizzato a un URL che rappresenta la chat room. Questa chat room è ospitata dal server SocialMiner e contiene il contatto del cliente o della chat.
Per installare il certificato SocialMiner nel browser, nel PC client passare a https://<FQDN SocialMiner>/ e installare il certificato tramite le richieste del browser.
Il certificato CUIC Tomcat può essere installato sul computer client per gli agenti, i supervisori e gli utenti di report che utilizzano l'interfaccia Web CUIC per i report cronologici o i report Live Data sia nella pagina Web CUIC che nei gadget sul desktop.
Per installare il certificato CUIC Tomcat nel browser, nel PC client passare a https://<UCCX FQDN>:8444/2010 e installare il certificato tramite le richieste del browser.
Certificato CUIC Live Data (dall'11.x)
CUIC utilizza il servizio I/O socket per i dati Live back-end. Questo certificato può essere installato sul computer client per gli agenti, i supervisori e gli utenti di report che utilizzano l'interfaccia Web CUIC per Live Data o che utilizzano i gadget Live Data all'interno di Finesse.
Per installare il certificato di I/O socket nel browser, nel PC client passare a https://<UCCX FQDN>:12015/12015 e installare il certificato tramite le richieste del browser.
Se uno script UCCX è progettato per accedere a una posizione sicura su un server di terze parti (ad esempio, il passaggio Ottieni documento URL per un URL HTTPS o Effettua una chiamata rimanente per un URL REST HTTPS), caricare la catena di certificati firmata o autofirmata del servizio di terze parti nel keystore UCCX tomcat-trust. Per ottenere questo certificato, accedere alla pagina Amministrazione del sistema operativo UCCX e scegliere Carica certificato.
Il motore UCCX è configurato in modo da ricercare nella piattaforma Tomcat keystore le catene di certificati di terze parti quando vengono presentati con questi certificati da applicazioni di terze parti quando accedono a percorsi sicuri tramite passaggi di script.
L'intera catena di certificati deve essere caricata nel keystore Tomcat della piattaforma, accessibile tramite la pagina di amministrazione del sistema operativo, poiché il keystore Tomcat non contiene certificati radice per impostazione predefinita.
Dopo aver completato queste azioni, riavviare Cisco UCCX Engine.
Per verificare che tutti i certificati siano installati correttamente, è possibile provare le funzionalità descritte in questa sezione. Se non vengono visualizzati errori e tutte le funzionalità funzionano correttamente, i certificati vengono installati correttamente.
UCCX Finesse Agents non è in grado di eseguire l'accesso. Errore "ID utente/password non valida".
Unified CCX genera un'eccezione "SSLHandshakeException" e non riesce a stabilire una connessione con Unified CM.
Il caricamento di un certificato firmato da un'autorità di certificazione visualizza l'errore "CSR SAN and Certificate SAN does not match".
La CA può aver aggiunto un altro dominio padre nel campo SAN (Subject Alternative Names) del certificato. Per impostazione predefinita, il CSR può avere le seguenti SAN:
NomeOggetto [
example.com (nomeDNS)
hostname.example.com (nomeDNS)
]
Le CA possono restituire un certificato con un'altra SAN aggiunta al certificato: Esempio di nome host. Il certificato può avere una SAN aggiuntiva in questo caso:
NomeOggetto [
example.com (nomeDNS)
hostname.example.com (nomeDNS)
www.hostname.example.com (dNSName)
]
Ciò causa un errore di mancata corrispondenza SAN.
Nella sezione Nome soggetto alternativo (SAN) della pagina UCCX - Genera richiesta di firma del certificato, generare il CSR con un campo Dominio padre vuoto. In questo modo, il CSR non viene generato con un attributo SAN, la CA può formattare le SAN e non vi può essere una mancata corrispondenza dell'attributo SAN quando si carica il certificato in UCCX. Si noti che per impostazione predefinita il campo Dominio padre corrisponde al dominio del server UCCX, pertanto il valore deve essere rimosso in modo esplicito durante la configurazione delle impostazioni per CSR.
Quando si accede a una qualsiasi pagina Web di UCCX, MediaSense o SocialMiner, viene visualizzato un messaggio di errore.
"La tua connessione non è privata. Gli aggressori possono tentare di rubare le informazioni da <FQDN_server>, ad esempio password, messaggi o carte di credito. NET::ERR_CERT_COMMON_NAME_INVALID. Impossibile provare che il server è <FQDN_server>. Il certificato di protezione proviene da [missing_subjectAltName]. Ciò può essere causato da una configurazione errata o da un utente non autorizzato che intercetta la connessione."
Chrome versione 58 ha introdotto una nuova funzione di sicurezza in cui segnala che il certificato di un sito web non è sicuro se il suo nome comune (CN) non è incluso anche come SAN.
Vedere la sezione Rimuovere il supporto per la corrispondenza di commonName nei certificati in Deprecazioni e rimozioni in Chrome 58.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
3.0 |
19-Sep-2024 |
Traduzione automatica e formattazione aggiornate. |
2.0 |
20-Oct-2023 |
Testo alternativo aggiunto.
Aggiornamento di titolo, introduzione, PII, SEO, dichiarazione di non responsabilità, traduzione automatica, requisiti di stile e formattazione. |
1.0 |
24-Mar-2015 |
Versione iniziale |