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 die SHA-256-Unterstützung für Cisco Unified Contact Center Express (UCCX) beschrieben. Die SHA-1-Verschlüsselung wird bald veraltet sein, und alle unterstützten Webbrowser für UCCX werden damit beginnen, Webseiten von Servern zu blockieren, die Zertifikate mit der SHA-1-Verschlüsselung anbieten.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Aktualisierung der SHA-1-Abschreibung
Weiterhin Auslaufen von SHA-1-Zertifikaten
In diesen Hinweisen haben die Browser-Hersteller angegeben, dass die Browser umgehbare Warnungen für aufgetretene SHA-1-Zertifikate anzeigen werden, die mit ValidFrom-Daten nach dem 1. Januar 2016 ausgestellt werden.
Darüber hinaus ist der aktuelle Plan zur Aufzeichnung, Websites zu blockieren, die nach dem 1. Januar 2017 SHA-1-Zertifikate verwenden, unabhängig vom ValidFrom-Eintrag im Zertifikat. Bei den jüngsten Angriffen, die auf SHA-1-Zertifikate abzielen, könnten diese Browser jedoch diese Zeitleiste nach oben verschieben und Websites blockieren, die nach dem 1. Januar 2017 SHA-1-Zertifikate verwenden, unabhängig vom Ausstellungsdatum des Zertifikats.
Cisco empfiehlt seinen Kunden, die Ankündigungen genau zu lesen und sich über weitere Ankündigungen von Microsoft und Mozilla zu diesem Thema auf dem Laufenden zu halten.
Einige Versionen von UCCX generieren SHA-1-Zertifikate. Wenn Sie auf mit SHA-1-Zertifikaten geschützte UCCX-Webseiten zugreifen, können diese eine Warnung auslösen oder gemäß den zuvor genannten Daten und Regeln gesperrt werden.
Wenn ein SHA-1-Zertifikat erkannt wird, wird dem Benutzer abhängig vom ValidFrom-Datum und den zuvor aufgeführten Regeln möglicherweise eine Meldung wie diese angezeigt:
Abhängig von den getroffenen Entscheidungen kann es vorkommen, dass ein Benutzer diese Warnung umgehen kann.
Diese Tabellen beschreiben die Auswirkungen auf das SHA-1-Zertifikat und Strategien zur Risikominimierung für jede Version von UCCX, die derzeit von der Software gewartet wird.
Anmerkung | Beschreibung |
Wird bereits unterstützt. Keine weiteren Maßnahmen erforderlich. | |
Unterstützung ist verfügbar, die Erneuerung von Zertifikaten ist jedoch erforderlich. | |
Der Support ist nicht verfügbar. |
UCCX-Administration | CUIC-Verwaltung Live-Daten# |
Finesse-Verwaltungsdesktop# | Agenten-E-Mail und Chat mit SocialMiner* | UCCX REST-Skriptschritte | Aufnahme mit MediaSense* 11.5 |
|
Neuinstallation | ||||||
Upgrade von vorheriger Version |
In den UCCX-Zertifikaten wird der Algorithmus aus älteren Versionen beibehalten. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
Die UCCX-Zertifikate von Cisco Unified Intelligence Center (CUIC) behalten den Algorithmus aus älteren Versionen bei. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
Die UCCX Finesse-Zertifikate behalten den Algorithmus aus älteren Versionen bei. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
Das SocialMiner- und das UCCX-Zertifikat behalten den Algorithmus aus älteren Versionen bei. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
UCCX lehnt keinen Remote-Webserver ab, der SHA-1-Zertifikate als Teil der REST-Kommunikation (Representational State Transfer) verwendet. Die REST-Schritte funktionieren, nachdem die Zertifikate auf dem UCCX neu generiert wurden. |
Das MediaSense- und das UCCX-Zertifikat behalten den Algorithmus aus älteren Versionen bei. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
Hinweis: *Die regenerierten MediaSense- und SocialMiner-Zertifikate müssen erneut in UCCX importiert werden.
Hinweis: Für Finesse und CUIC sind separate #No Aktionen erforderlich. Die Zertifikate werden nur einmal auf der Verwaltungsseite der UCCX-Plattform neu generiert.
UCCX-Administration | CUIC-Administration - Live-Daten# | Finesse-Verwaltungsdesktop# | Agent E-Mail und Chat mit SocialMiner** | UCCX REST-Skriptschritte | Aufzeichnung mit MediaSense** 11.0* und 10.5* | |
Neuinstallation |
Standardmäßig sind alle selbstsignierten Zertifikate für Neuinstallationen SHA-1-Zertifikate und müssen neu generiert werden. |
Standardmäßig sind alle selbstsignierten Zertifikate für Neuinstallationen SHA-1-Zertifikate und müssen neu generiert werden. |
Standardmäßig sind alle selbstsignierten Zertifikate für Neuinstallationen SHA-1-Zertifikate und müssen neu generiert werden. |
Standardmäßig sind alle selbstsignierten Zertifikate für Neuinstallationen SHA-1-Zertifikate und müssen neu generiert werden. |
UCCX lehnt keinen Remote-Webserver ab, der SHA-1-Zertifikate als Teil der REST-Kommunikation verwendet. Die REST-Schritte funktionieren, nachdem die Zertifikate auf dem UCCX neu generiert wurden. |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
Upgrade von vorheriger Version |
In den UCCX-Zertifikaten wird der Algorithmus aus älteren Versionen beibehalten. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
Die UCCX CUIC-Zertifikate behalten den Algorithmus aus älteren Versionen bei. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
Die UCCX Finesse-Zertifikate behalten den Algorithmus aus älteren Versionen bei. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
Das SocialMiner- und das UCCX-Zertifikat behalten den Algorithmus aus älteren Versionen bei. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
UCCX lehnt keinen Remote-Webserver ab, der SHA-1-Zertifikate als Teil der REST-Kommunikation verwendet. Die REST-Schritte funktionieren, nachdem die Zertifikate auf dem UCCX neu generiert wurden. |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
Hinweis: *Es wird eine Engineering Special (ES) veröffentlicht, damit MediaSense 10.5 und 11.0 SHA-256-Zertifikate generieren und akzeptieren kann.
Hinweis: **Die regenerierten MediaSense- und SocialMiner-Zertifikate müssen erneut in UCCX importiert werden.
Hinweis: Für Finesse und CUIC sind separate #No Aktionen erforderlich. Die Zertifikate werden nur einmal auf der Verwaltungsseite der UCCX-Plattform neu generiert.
UCCX-Administration | CUIC-Administration - Live-Daten# | Finesse-Verwaltungsdesktop# | Agenten-E-Mail und Chat mit SocialMiner* | UCCX REST-Skriptschritte | Aufnahme mit MediaSense*** 10.0** / 10.5** | |
Neuinstallation |
Standardmäßig sind alle selbstsignierten Zertifikate für Neuinstallationen SHA-1-Zertifikate und müssen neu generiert werden. |
Standardmäßig sind alle selbstsignierten Zertifikate für Neuinstallationen SHA-1-Zertifikate und müssen neu generiert werden. |
Standardmäßig sind alle selbstsignierten Zertifikate für Neuinstallationen SHA-1-Zertifikate und müssen neu generiert werden. |
SHA-256-Unterstützung für Agenten-E-Mail und -Chat ist nur in SocialMiner (SM) v11 verfügbar, und SM v11 ist nicht mit UCCX v10.x kompatibel. |
UCCX lehnt keinen Remote-Webserver ab, der SHA-1-Zertifikate als Teil der REST-Kommunikation verwendet. Die REST-Schritte funktionieren, nachdem die Zertifikate auf dem UCCX neu generiert wurden. |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
Upgrade von vorheriger Version |
In den Zertifikaten wird der Algorithmus aus älteren Versionen beibehalten. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
In den Zertifikaten wird der Algorithmus aus älteren Versionen beibehalten. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
In den Zertifikaten wird der Algorithmus aus älteren Versionen beibehalten. Wenn die selbstsignierten Zertifikate in älteren Versionen mit einem SHA-11-Schlüssel generiert werden, sind sie SHA-1-basiert und müssen neu generiert werden. |
SHA-256-Unterstützung für Agenten-E-Mail und -Chat ist nur in SM v11 verfügbar und SM v11 ist nicht mit UCCX v10.x kompatibel. |
UCCX lehnt keinen Remote-Webserver ab, der SHA-1-Zertifikate als Teil der REST-Kommunikation verwendet. Die REST-Schritte funktionieren, nachdem die Zertifikate auf dem UCCX neu generiert wurden. |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
Hinweis: *Es wird eine technische Sonderaktion veröffentlicht, damit SocialMiner 10.6 SHA-256-Zertifikate generieren und akzeptieren kann.
Hinweis: **Es wird eine Engineering Special (ES) veröffentlicht, damit MediaSense 10.0 und 10.5 SHA-256-Zertifikate generieren und akzeptieren kann.
Hinweis: ***Die regenerierten MediaSense- und SocialMiner-Zertifikate müssen erneut in UCCX importiert werden.
Hinweis: Für Finesse und CUIC sind separate #No Aktionen erforderlich. Die Zertifikate werden nur einmal auf der Verwaltungsseite der UCCX-Plattform neu generiert.
UCCX-Administration** | CUIC-Administration - Live-Daten# | Finesse-Verwaltungsdesktop# | Agent-Chat mit SocialMiner* | UCCX REST-Skriptschritte | Aufnahme mit MediaSense*** 10.0** | |
Neuinstallation |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
SHA-256-Unterstützung für Agenten-Chat ist nur in SM v11 verfügbar, SM v11 ist nicht mit UCCX v10.x kompatibel. |
UCCX lehnt keinen Remote-Webserver ab, der SHA-1-Zertifikate als Teil der REST-Kommunikation verwendet. Die REST-Schritte funktionieren, nachdem die Zertifikate auf dem UCCX neu generiert wurden. |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
Upgrade von vorheriger Version |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
SHA-256-Unterstützung für Agenten-Chat ist nur in SM v11 verfügbar, SM v11 ist nicht mit UCCX v10.x kompatibel. |
UCCX lehnt keinen Remote-Webserver ab, der SHA-1-Zertifikate als Teil der REST-Kommunikation verwendet. Die REST-Schritte funktionieren, nachdem die Zertifikate auf dem UCCX neu generiert wurden. |
Das selbstsignierte Standardzertifikat ist SHA-1. Das Regenerationszertifikat bietet keine Option für SHA-256. |
Hinweis: *Es wird eine technische Sonderaktion veröffentlicht, damit SocialMiner 10.6 SHA-256-Zertifikate generieren und akzeptieren kann.
Hinweis: **Es wird eine Engineering Special (ES) veröffentlicht, damit MediaSense 10.0 SHA-256-Zertifikate generieren und akzeptieren kann.
Hinweis: ***Die regenerierten MediaSense- und SocialMiner-Zertifikate müssen erneut in UCCX importiert werden.
Hinweis: Für Finesse und CUIC sind separate #No Aktionen erforderlich. Die Zertifikate werden nur einmal auf der Verwaltungsseite der UCCX-Plattform neu generiert.
Es gibt drei Arten von Zertifikaten, die überprüft und möglicherweise neu generiert werden müssen:
Navigieren Sie zur Seite OS Administration (Betriebssystemverwaltung). Wählen Sie Sicherheit > Navigieren Sie zur Zertifikatsverwaltung. Klicken Sie auf Suchen.
Beachten Sie die vier Zertifikatkategorien:
Die Zertifikate unter der Kategorie tomcat und Typ Self-signed sind diejenigen, die regeneration erfordern. Im vorherigen Bild ist das dritte Zertifikat das Zertifikat, das regeneriert werden muss.
Führen Sie die folgenden Schritte aus, um die Zertifikate neu zu generieren:
Schritt 1: Klicken Sie auf den allgemeinen Namen des Zertifikats.
Schritt 2: Klicken Sie im Popup-Fenster auf Regenerieren.
Schritt 3: Wählen Sie den Verschlüsselungsalgorithmus SHA-256 aus.
Führen Sie für UCCX Version 10.6 die folgenden Schritte aus, um die Zertifikate neu zu generieren:
Schritt 1: Klicken Sie auf Neu erstellen.
Schritt 2: Wählen Sie Zertifikatname als tomcat, Schlüssellänge als 2048 und Hashalgorithmus als SHA256 aus.
Schritt 3: Klicken Sie auf Neu erstellen.
Dies sind die Zertifikate, die von der Plattform bereitgestellt werden. SHA-1-basierte Signaturen für diese Zertifikate stellen kein Problem dar, da diese Zertifikate von den TLS-Clients (Transport Layer Security) anhand ihrer Identität und nicht anhand der Signatur ihres Hashs als vertrauenswürdig eingestuft werden.
Zertifikate, die von einer unabhängigen Zertifizierungsstelle mit dem SHA-1-Algorithmus unterzeichnet wurden, müssen mit SHA-256-signierten Zertifikaten erneut importiert werden. Alle Zertifikate in einer Zertifikatskette müssen mit SHA-256 neu signiert werden.
Die neuesten Engineering Specials stehen auf cisco.com zur Verfügung. Auf den entsprechenden Produktseiten finden Sie regelmäßig die Engineering Special Downloads.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
05-Apr-2016 |
Erstveröffentlichung |