In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie Cisco Unified Contact Center Express (UCCX) für die Verwendung von selbstsignierten und signierten Zertifikaten konfiguriert wird.
Bevor Sie mit den in diesem Dokument beschriebenen Konfigurationsschritten fortfahren, stellen Sie sicher, dass Sie auf die Seite Betriebssystem-Administration für folgende Anwendungen zugreifen können:
Ein Administrator kann auch auf den Zertifikatsspeicher auf den Client-PCs des Agenten und Supervisors zugreifen.
Alle Server in der UCCX-Konfiguration müssen mit DNS-Servern (Domain Name System) und Domänennamen installiert werden. Außerdem müssen Agenten, Supervisoren und Administratoren über den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) auf die UCCX-Konfigurationsanwendungen zugreifen.
Wenn sich die Domäne ändert oder zum ersten Mal ausgefüllt wird, können die Zertifikate neu generiert werden. Nachdem Sie der Serverkonfiguration den Domänennamen hinzugefügt haben, müssen Sie alle Tomcat-Zertifikate neu generieren, bevor Sie sie in den anderen Anwendungen, im Clientbrowser oder bei Generierung der Zertifikatsignierungsanforderung (Certificate Signing Request, CSR) für die Signierung installieren.
Die in diesem Dokument beschriebenen Informationen basieren auf folgenden Hardware- und Softwarekomponenten:
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Mit der Einführung von Co-Resident Finesse und CUIC, der Integration von UCCX und SocialMiner für E-Mail und Chat und der Verwendung von MediaSense zum Aufzeichnen, Verstehen und Installieren von Zertifikaten über Finesse ist die Möglichkeit, Zertifikatprobleme zu beheben, von entscheidender Bedeutung geworden.
In diesem Dokument wird die Verwendung von selbstsignierten und signierten Zertifikaten in der UCCX-Konfigurationsumgebung beschrieben. Dabei werden folgende Punkte behandelt:
Zertifikate, signiert oder selbstsigniert, müssen sowohl auf den Anwendungen (Servern) in der UCCX-Konfiguration als auch auf den Client-Desktops der Agenten und Supervisoren installiert werden.
Die Multi-SAN-Unterstützung wurde in UCCX ab Version 11.6.2 hinzugefügt.
Öffentlich signierte CA-Zertifikate auf SomicalMiner/CCP sind erforderlich, damit externer Chat über das Internet funktioniert.
In diesem Abschnitt wird beschrieben, wie Sie das UCCX für die Verwendung von selbstsignierten und signierten Zertifikaten konfigurieren.
Die empfohlene Methode für das Zertifikatsmanagement für die UCCX-Konfiguration besteht in der Nutzung signierter Zertifikate. Diese Zertifikate können entweder von einer internen Zertifizierungsstelle (Certificate Authority, CA) oder einer bekannten Zertifizierungsstelle eines Drittanbieters signiert werden.
In gängigen Browsern wie Mozilla Firefox und Microsoft Edge werden standardmäßig Root-Zertifikate für bekannte Drittanbieter-CAs installiert. Die Zertifikate für UCCX-Konfigurationsanwendungen, die von diesen CAs signiert werden, sind standardmäßig vertrauenswürdig, da ihre Zertifikatkette in einem Stammzertifikat endet, das bereits im Browser installiert ist.
Das Stammzertifikat einer internen Zertifizierungsstelle kann auch im Clientbrowser über eine Gruppenrichtlinie oder eine andere aktuelle Konfiguration vorinstalliert werden.
Sie können wählen, ob die UCCX-Konfigurationsanwendungszertifikate von einer bekannten Drittanbieter-Zertifizierungsstelle oder von einer internen Zertifizierungsstelle signiert werden sollen. Dies hängt von der Verfügbarkeit und der Vorinstallation des Stammzertifikats für die Zertifizierungsstellen im Client-Browser ab.
Führen Sie die folgenden Schritte für jeden Knoten der UCCX Publisher- und Subscriber-, SocialMiner-, MediaSense Publisher- und Subscriber-Administrationsanwendungen aus:
Senden Sie den neuen CSR an die Drittanbieter-CA, oder signieren Sie ihn mit einer internen CA, wie zuvor beschrieben. Dieser Prozess kann folgende signierte Zertifikate erstellen:
Hinweis: Lassen Sie das Feld "Distribution" im CSR als FQDN des Servers unverändert.
Hinweis: Multi-Server (SAN)-Zertifikat wird für UCCX ab Version 11.6 unterstützt. Das SAN kann jedoch nur UCCX Node-1 und Node-2 enthalten. Andere Server wie SocialMiner können nicht in das SAN von UCCX eingebunden werden. Ein Beispiel für ein CUCM-SAN, das auch für UCCX gilt, finden Sie unten auf Seite.
Hinweis: UCCX unterstützt nur Zertifikatschlüssellängen von 1024 und 2048 Bit.
Führen Sie auf jedem Anwendungsserver die folgenden Schritte aus, um das Stammzertifikat und das Anwendungszertifikat auf die Knoten hochzuladen:
Hinweis: Wenn Sie das Root- und Zwischenzertifikat auf einen Herausgeber (UCCX oder MediaSense) hochladen, kann es automatisch auf den Abonnenten repliziert werden. Es ist nicht erforderlich, die Stamm- oder Zwischenzertifikate auf die anderen Server ohne Herausgeber in der Konfiguration hochzuladen, wenn alle Anwendungszertifikate über dieselbe Zertifikatskette signiert sind.
Hinweis: Wenn eine untergeordnete Zertifizierungsstelle das Zertifikat signiert, laden Sie das Stammzertifikat der untergeordneten Zertifizierungsstelle als das Tomcat-Trust-Zertifikat anstatt des Stammzertifikats hoch. Wenn ein Zwischenzertifikat ausgestellt wurde, laden Sie dieses Zertifikat zusätzlich zum Anwendungszertifikat in den Tomcat-Trust-Speicher hoch.
Hinweis: Wenn Sie UCCX und SocialMiner 11.5 verwenden, gibt es ein neues Zertifikat namens tomcat-ECDSA. Wenn Sie ein signiertes Tomcat-ECDSA-Zertifikat auf den Server hochladen, laden Sie das Anwendungszertifikat als Tomcat-ECDSA-Zertifikat hoch - nicht als Tomcat-Zertifikat. Weitere Informationen zu ECDSA finden Sie im Abschnitt "Related Information" (Verwandte Informationen) unter dem Link zum Verständnis und zur Konfiguration von ECDSA-Zertifikaten. Ab dem 11.6. wurde die Verwendung von ECDSA-Zertifikaten aus der UCCX-Lösung vollständig entfernt. Dazu gehören UCCX, SM/CCP, CUIC und Finesse.
Alle Zertifikate, die in der UCCX-Konfiguration verwendet werden, sind auf den Konfigurationsanwendungen vorinstalliert und selbstsigniert. Diese selbstsignierten Zertifikate sind nicht implizit vertrauenswürdig, wenn sie einem Clientbrowser oder einer anderen Konfigurationsanwendung vorgelegt werden. Es wird zwar empfohlen, alle Zertifikate in der UCCX-Konfiguration zu signieren, Sie können jedoch die vorinstallierten selbstsignierten Zertifikate verwenden.
Für jede Anwendungsbeziehung müssen Sie das entsprechende Zertifikat herunterladen und in die Anwendung hochladen. Gehen Sie wie folgt vor, um die Zertifikate zu erhalten und hochzuladen:
Um selbstsignierte Zertifikate auf dem Client-Computer zu installieren, verwenden Sie eine Gruppenrichtlinie oder einen Paketmanager, oder installieren Sie sie einzeln im Browser jedes Agenten-PCs.
Installieren Sie für Microsoft Edge die clientseitigen selbstsignierten Zertifikate im Speicher der vertrauenswürdigen Stammzertifizierungsstellen.
Führen Sie für Mozilla Firefox die folgenden Schritte aus:
Falls selbstsignierte Zertifikate ablaufen, müssen sie neu generiert werden, und die Konfigurationsschritte von Installation auf Peripherieservern müssen erneut ausgeführt werden.
Das UCCX nutzt die REST- und Benachrichtigungs-APIs von SocialMiner, um E-Mail-Kontakte und -Konfigurationen zu verwalten. Beide UCCX-Knoten müssen die REST-API von SocialMiner nutzen und vom Benachrichtigungsdienst von SocialMiner benachrichtigt werden. Installieren Sie daher das SocialMiner Tomcat-Zertifikat auf beiden UCCX-Knoten.
Laden Sie die signierte oder selbstsignierte Zertifikatskette des SocialMiner-Servers in den UCCX-Schlüsselspeicher für Tomcat-Trust hoch.
Laden Sie das UCCX-Tomcat-Zertifikat von Publisher- und Subscriber-Knoten als Tomcat-Trust-Keystore auf den SocialMiner-Server hoch.
Das UCCX AppAdmin-Client-Zertifikat wird für die Administration des UCCX-Systems verwendet. Um das UCCX AppAdmin-Zertifikat für UCCX-Administratoren auf dem Client-PC zu installieren, navigieren Sie für jeden UCCX-Knoten zu https://<UCCX FQDN>/appadmin/main, und installieren Sie das Zertifikat über den Browser.
Die UCCX-Webdienste werden für die Übermittlung von Chat-Kontakten an Client-Browser verwendet. Um das UCCX-Plattformzertifikat für UCCX-Agenten und -Supervisoren auf dem Client-PC zu installieren, navigieren Sie zu https://<UCCX FQDN>/appadmin/main für jeden UCCX-Knoten, und installieren Sie das Zertifikat über den Browser.
Der CCX Notification Service wird von Finesse, UCCX und CUIC verwendet, um Echtzeitinformationen über Extensible Messaging and Presence Protocol (XMPP) an den Client-Desktop zu senden. Diese Funktion wird für die Echtzeit-Kommunikation mit Finesse sowie für CUIC Live Data verwendet.
Um das Notification Service-Client-Zertifikat auf dem PC der Agenten und Supervisoren oder Reporting-Benutzer zu installieren, die Live Data verwenden, navigieren Sie für jeden UCCX-Knoten zu https://<UCCX FQDN>:7443/, und installieren Sie das Zertifikat über den Browser.
Das Finesse Client-Zertifikat wird von den Finesse-Desktops verwendet, um eine Verbindung zur Finesse Tomcat-Instanz für die REST-API-Kommunikation zwischen dem Desktop und dem mitresidierenden Finesse-Server herzustellen.
Um das Finesse-Zertifikat für Agenten und Supervisoren auf dem Client-PC zu installieren, navigieren Sie für jeden UCCX-Knoten zu https://<UCCX FQDN>:8445/, und installieren Sie das Zertifikat über die Browser-Eingabeaufforderungen.
Um das Finesse-Zertifikat für Finesse-Administratoren auf dem Client-PC zu installieren, navigieren Sie für jeden UCCX-Knoten zu https://<UCCX FQDN>:8445/cfadmin, und installieren Sie das Zertifikat über die Browser-Eingabeaufforderungen.
Das SocialMiner Tomcat-Zertifikat muss auf dem Client-Computer installiert sein. Sobald ein Mitarbeiter eine Chat-Anfrage annimmt, wird das Chat-Gadget an eine URL umgeleitet, die den Chat-Raum darstellt. Dieser Chat-Raum wird vom SocialMiner-Server gehostet und enthält den Kunden- oder Chat-Kontakt.
Um das SocialMiner-Zertifikat im Browser zu installieren, navigieren Sie auf dem Client-PC zu https://<SocialMiner FQDN>/ und installieren Sie das Zertifikat über die Browser-Eingabeaufforderungen.
Das CUIC Tomcat-Zertifikat kann auf dem Client-Computer für Agenten, Supervisoren und Benutzer installiert werden, die die CUIC-Webschnittstelle für Verlaufsberichte oder Live Data-Berichte verwenden. Dies ist entweder auf der CUIC-Webseite oder in den Gadgets auf dem Desktop möglich.
Um das CUIC Tomcat-Zertifikat im Browser auf dem Client-PC zu installieren, navigieren Sie zu https://<UCCX FQDN>:8444/ und installieren Sie das Zertifikat über die Browser-Eingabeaufforderungen.
CUIC Live Data-Zertifikat (seit 11.x)
Der CUIC verwendet den Socket-E/A-Dienst für die Live-Backend-Daten. Dieses Zertifikat kann auf dem Client-Computer für Agenten, Supervisoren und Reporting-Benutzer installiert werden, die die CUIC-Webschnittstelle für Live-Daten verwenden oder die Live-Daten-Gadgets in Finesse verwenden.
Um das Socket IO-Zertifikat im Browser zu installieren, navigieren Sie auf dem Client-PC zu https://<UCCX FQDN>:12015/ und installieren Sie das Zertifikat über die Browser-Eingabeaufforderungen.
Wenn ein UCCX-Skript für den Zugriff auf einen sicheren Speicherort auf einem Drittanbieterserver entwickelt wurde (z. B. Schritt "URL-Dokument abrufen" auf eine HTTPS-URL oder "REST-Anruf tätigen" auf eine HTTPS-REST-URL), laden Sie die signierte oder selbstsignierte Zertifikatkette des Drittanbieterdiensts in den UCCX-Tomcat-Trust-Schlüsselspeicher hoch. Um dieses Zertifikat zu erhalten, rufen Sie die Seite UCCX OS Administration (UCCX-BS-Administration) auf, und wählen Sie Upload Certificate (Zertifikat hochladen).
Die UCCX-Engine ist so konfiguriert, dass die Plattform Tomcat Keystore nach Zertifikatsketten von Drittanbietern durchsucht wird, wenn diese Zertifikate von Drittanbieteranwendungen bereitgestellt werden, wenn diese über Skriptschritte auf sichere Standorte zugreifen.
Die gesamte Zertifikatskette muss in den Tomcat-Schlüsselspeicher der Plattform hochgeladen werden, auf den über die Seite OS Administration zugegriffen werden kann, da der Tomcat-Schlüsselspeicher standardmäßig keine Root-Zertifikate enthält.
Starten Sie nach Abschluss dieser Aktionen die Cisco UCCX Engine neu.
Um sicherzustellen, dass alle Zertifikate korrekt installiert sind, können Sie die in diesem Abschnitt beschriebenen Funktionen testen. Wenn keine Zertifikatfehler angezeigt werden und alle Funktionen ordnungsgemäß funktionieren, werden die Zertifikate richtig installiert.
UCCX Finesse Agents können sich nicht mit der Fehlermeldung "Invalid User ID/Password" (Ungültige Benutzer-ID/Kennwort) anmelden.
Unified CCX löst eine Ausnahme "SSLHandshakeException" aus und kann keine Verbindung mit Unified CM herstellen.
Beim Hochladen eines CA-signierten Zertifikats wird der Fehler "CSR SAN and Certificate SAN does not match" angezeigt.
Die Zertifizierungsstelle kann eine weitere übergeordnete Domäne in das Feld Subjekt Alternative Namen (SAN) des Zertifikats eingefügt haben. Standardmäßig kann der CSR die folgenden SANs aufweisen:
SubjectAltName [
example.com (dnsnName)
hostname.example.com (dnsnName)
]
Die CAs können ein Zertifikat zurückgeben, dem ein anderes SAN hinzugefügt wurde: Beispiel für Hostnamen. Das Zertifikat kann in diesem Fall über ein zusätzliches SAN verfügen:
SubjectAltName [
example.com (dnsnName)
hostname.example.com (dnsnName)
www.hostname.example.com (dNSName)
]
Dies verursacht den SAN-Diskrepanzfehler.
Generieren Sie im Abschnitt "Subject Alternate Name (SANs)" der Seite "UCCX Generate Certificate Signing Request" den CSR mit einem leeren Feld "Parent Domain" (Übergeordnete Domäne). Auf diese Weise wird der CSR nicht mit einem SAN-Attribut generiert, die CA kann die SANs formatieren, und es darf keine SAN-Attribut-Diskrepanz geben, wenn Sie das Zertifikat in UCCX hochladen. Beachten Sie, dass das Feld "Parent Domain" (Übergeordnete Domäne) standardmäßig die Domäne des UCCX-Servers enthält. Der Wert muss daher explizit entfernt werden, während die Einstellungen für den CSR konfiguriert werden.
Wenn Sie auf eine UCCX-, MediaSense- oder SocialMiner-Webseite zugreifen, wird eine Fehlermeldung angezeigt.
"Ihre Verbindung ist nicht privat. Angreifer versuchen möglicherweise, Ihre Daten von <Server_FQDN> zu stehlen (z. B. Kennwörter, Nachrichten oder Kreditkarten). NET::ERR_CERT_COMMON_NAME_INVALID. Dieser Server konnte nicht nachweisen, dass er <Server_FQDN> ist; sein Sicherheitszertifikat stammt von [missing_subjectAltName]. Dies kann durch eine falsche Konfiguration oder durch einen Angreifer verursacht werden, der Ihre Verbindung abfängt."
Chrome Version 58 führte eine neue Sicherheitsfunktion ein, bei der es berichtet, dass das Zertifikat einer Website nicht sicher ist, wenn sein gemeinsamer Name (CN) nicht auch als SAN enthalten ist.
Siehe Abschnitt Entfernen Unterstützung für commonName-Matching in Zertifikaten in Deprecations und Removals in Chrome 58.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
3.0 |
19-Sep-2024 |
Aktualisierte maschinelle Übersetzung und Formatierung. |
2.0 |
20-Oct-2023 |
Alternativer Text hinzugefügt.
Aktualisierter Titel, Einführung, PII, SEO, Haftungsausschluss, maschinelle Übersetzung, Stilanforderungen und Formatierung. |
1.0 |
24-Mar-2015 |
Erstveröffentlichung |