CUCM-Zertifikatregeneration/-verlängerung
Inhalt
Einführung
Voraussetzungen Anforderungen
Verwendete Komponenten
Wann werden Zertifikate neu generiert?
Auswirkungen des Service durch den Zertifikatsspeicher DRS-Sicherung erstellen
Bestimmen des gemischten Modus
Wenn sich der Cluster im gemischten Modus befindet Standardmäßige Überprüfung der Sicherheit im Cluster
Verwenden des Prepare-Clusters für die Funktion "Rollback to pre 8.0"
Regenerieren von Zertifikaten in einer bestimmten Bestellung Entfernen und Neuerstellen von Zertifikaten in CUCM
Regenerieren von Zertifikaten über die CLI Was ist zu erwarten?
Entfernen von Zertifikaten über die CLI
Regenerieren von Zertifikaten über die Web-GUI Entfernen von Zertifikaten über die Web-GUI
Nach der Regeneration/Entfernung von Zertifikaten Installieren/Aktualisieren von LSC auf dem Telefon Schlussfolgerung
Einführung
In diesem Dokument wird beschrieben, wie Sie die in Cisco Unified Communications Manager (CUCM) Version 8.x und höher verwendeten Zertifikate neu generieren. Die Standardfunktionen
"Security by Default" (ITL) und "Mixed-Mode (CTL)" (Sicherheit im gemischten Modus) werden ebenfalls abgedeckt, um unerwünschte Ausfälle zu vermeiden. So können Sie beispielsweise Probleme bei der Telefonregistrierung vermeiden oder Telefone, die keine
Konfigurationsänderungen oder Firmware akzeptieren.
Vorsicht: Es wird immer empfohlen, die Zertifikatswiederherstellung in einem Wartungsfenster abzuschließen.
Voraussetzungen
Anforderungen
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
CallManager
●
CAPF (Certificate Authority Proxy Function)
●
IPsec
●
Tomate
●
TVS (Trust Verification Service)
●
ITLR-Wiederherstellung (nur für CUCM 10.X und höher)
●
phone-vpn-trust
●
telefonvertrauen
●
Telefonvertrauen
●
phone-ctl trust
●
LSCs (lokal bedeutsame Zertifikate)
●
MICs (Vom Hersteller installierte Zertifikate)
●
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen:
CUCM Version 9.1(2)SU2a,
●
CUCM ab Version 8.x
●
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten
Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Wann werden Zertifikate neu generiert?
Die meisten Zertifikate, die nach einer Neuinstallation in CUCM verwendet werden, sind selbstsignierte Zertifikate, die standardmäßig für einen Zeitraum von fünf Jahren ausgestellt werden. Beachten Sie, dass der Zeitraum von fünf Jahren für CUCM derzeit nicht auf einen kürzeren Zeitraum geändert werden kann. Eine Zertifizierungsstelle (Certificate Authority, CA) kann Zertifikate jedoch für nahezu jeden Zeitraum ausstellen.
Es gibt auch einige vertrauenswürdige Zertifikate (wie CAPF-trust und CallManager-trust), die vorgeladen werden und eine längere Gültigkeitsdauer haben. Das Zertifikat der Cisco
Manufacturing CA wird beispielsweise in CUCM Trust Stores für bestimmte Funktionen bereitgestellt und läuft erst ab 2029 ab.
Zertifikate sollten neu generiert werden, bevor sie ablaufen. Wenn die Zertifikate bald ablaufen, erhalten Sie Warnungen im RTMT (Syslog Viewer) und eine E-Mail mit der Benachrichtigung, falls konfiguriert.
Ein Beispiel für eine Zertifikatsablaufbenachrichtigung, in der das CUCM01.der-Zertifikat detailliert abläuft, ist der 19. Mai 14:46 auf dem Server-CUCM02 im Trust Store tomcat-trust angezeigt wird:
At Fri Sep 05 02:00:56 CEST 2014 on node 192.168.1.2, the following SyslogSeverityMatchFound events generated:
SeverityMatch : Critical
MatchedEvent : Sep 5 02:00:06 CUCM02 local7 2 : 864: CUCM02.localdomain:
Sep 05 2014 00:00:06.433 UTC : %UC_CERT-2-CertValidfor7days:
%[Message=Certificate expiration Notification. Certificate name:CUCM01.der Unit:tomcat-trust Type:own-cert Expiration:Mon May 19 14:46:]
[AppID=Cisco Certificate Monitor][ClusterID=][NodeID=CUCM02]:
Alarm to indicate that Certificate has Expired or Expires in less than seven days AppID : Cisco Syslog Agent
ClusterID : NodeID : CUCM02
TimeStamp : Fri Sep 05 02:00:16 CEST 2014
Wenn die Dienstzertifikate (Zertifikatsspeicher, die nicht mit -trust gekennzeichnet sind) bereits abgelaufen sind, können sie trotzdem neu generiert werden. Beachten Sie, dass abgelaufene Zertifikate je nach Konfiguration des Clusters Auswirkungen auf Ihre CUCM-Funktionalität haben können. Überlegungen werden in den nächsten Abschnitten behandelt.
Auswirkungen des Service durch den Zertifikatsspeicher
Für die gute Systemfunktionalität ist es wichtig, dass alle Zertifikate im CUCM-Cluster aktualisiert werden. Wenn Ihre Zertifikate abgelaufen oder ungültig sind, können sie die normale
Funktionsweise des Systems erheblich beeinträchtigen. Eine Liste potenzieller Probleme, die auftreten können, wenn eines der Zertifikate ungültig oder abgelaufen ist, wird hier angezeigt. Der Unterschied in den Auswirkungen kann von der Systemeinrichtung abhängen.
CallManager.pem
TFTP nicht vertrauenswürdig (Telefone akzeptieren keine signierten Konfigurationsdateien und/oder ITL-Dateien).
●
Telefondienste sind möglicherweise betroffen.
●
SIP-Trunks (Secure Session Initiation Protocol) oder Medienressourcen (Konferenzbrücken, MTP (Media Termination Point), Xcoder usw.) können nicht registriert oder verwendet werden.
●
Die AXL-Anforderung schlägt fehl.
●
Tomcat.pem
Telefone können nicht auf HTTP-Dienste zugreifen, die auf dem CUCM-Knoten gehostet werden, z. B. das Firmenverzeichnis.
●
Die Web-GUI-Probleme von CUCM, z. B. der nicht auf Serviceseiten von anderen Knoten im Cluster zugreifen kann.
●
Cluster-übergreifende Probleme bei Extension Mobility oder Extension Mobility.
●
Wenn UCCX (Unified Contact Center Express) integriert ist, muss aufgrund von
Sicherheitsänderungen von CCX 12.5 das CUCM Tomcat-Zertifikat (selbstsigniert) oder das Tomcat Root & Intermediate-Zertifikat (für CA signiert) im UCCX Tomcat-Trust-Store
hochgeladen werden, da sich Finesse Desktop-Anmeldungen auswirken.
●
CAPF.pem
Telefone authentifizieren sich nicht für Telefon-VPN, 802.1x oder Telefon-Proxy.
●
LSC-Zertifikate für Telefone können nicht ausgegeben werden.
●
Verschlüsselte Konfigurationsdateien funktionieren nicht.
●
IPSec.pem
Disaster Recovery System (DRS)/Disaster Recovery Framework (DRF) funktionieren
●
möglicherweise nicht ordnungsgemäß.
IPsec-Tunnel zum Gateway (GW) zu anderen CUCM-Clustern funktionieren nicht.
●
Trust Verification Service (TVS)
Das Telefon kann den HTTPS-Dienst nicht authentifizieren. Das Telefon kann keine
Konfigurationsdateien authentifizieren (dies kann sich auf fast alles auf dem CUCM auswirken).
phone-vpn-trust
Das Telefon-VPN funktioniert nicht, da die HTTPS-URL des VPN nicht authentifiziert werden kann.
Hinweis: Wenn dies nicht vorhanden ist keine Sorge. Dies gilt nur für bestimmte Konfigurationen.
telefonvertrauen
Bisherige CTL/eToken können die CTL nicht aktualisieren oder ändern.
Hinweis: Wenn dies nicht vorhanden ist keine Sorge. Dies gilt nur für bestimmte Konfigurationen.
Telefonvertrauen und Telefon-ctl-trust
Visual Voicemail mit Unity oder Unity Connection funktioniert nicht.
Hinweis: Wenn dies nicht vorhanden ist keine Sorge. Dies gilt nur für bestimmte Konfigurationen.
LSCs und MICs
Telefone registrieren sich nicht, das Telefon authentifiziert sich nicht bei Telefon-VPN, Telefon- Proxy oder 802.1x.
Hinweis: MICs sind in den meisten Telefonmodellen standardmäßig enthalten. LSCs werden standardmäßig von CAPF signiert und haben eine Laufzeit von fünf Jahren. Software-Clients wie CIPC (Cisco IP Communicator) und Jabber verfügen nicht über eine MIC.
DRS-Sicherung erstellen
Es wird empfohlen, eine DRS-Sicherung zu erstellen, bevor Sie größere Änderungen wie diese durchführen. CUCM DRF-Sicherungen sichern alle Zertifikate im Cluster. Alle DRS-Sicherungs- /Wiederherstellungsverfahren finden Sie im Cisco Disaster Recovery System Administration Guide for Cisco Unified Communications Manager.
Vorsicht: Beachten Sie, dass die Cisco Bug-ID CSCtn50405 Zertifikate nicht durch CUCM DRF Backup gesichert werden.
Bestimmen des gemischten Modus
Um zu bestimmen, ob Sie ein CTL-/Secure-/Mixed-Mode-Cluster ausführen, wählen Sie Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 ==
Unsicher; 1 == Gemischter Modus).
Wenn sich der Cluster im gemischten Modus befindet
Wenn Sie einen CUCM-Cluster im gemischten Modus ausführen, bedeutet dies, dass die CTL- Datei aktualisiert werden muss, nachdem alle Zertifikatsänderungen vorgenommen wurden. Die Vorgehensweise hierzu finden Sie in der Cisco Security Guide-Dokumentation. Stellen Sie jedoch sicher, dass Sie mindestens ein eToken von der ursprünglichen Initiierung der Mixed-Mode- Funktion haben und das eToken-Kennwort bekannt ist.
Hinweis: Eine Aktualisierung der CTL erfolgt nicht automatisch (wie bei der ITL-Datei). Sie muss vom Administrator manuell entweder mit dem CTL-Client oder dem CLI-Befehl ausgeführt werden.
In CUCM 10.X und höher können Sie den Cluster auf zwei Arten in den gemischten Modus setzen:
CLI-Befehl: Wenn diese Methode verwendet wird, wird die CTL-Datei mit dem CallManager.pem-Zertifikat des Publisher-Servers signiert.
admin:show ctl
The checksum value of the CTL file:
0c05655de63fe2a042cf252d96c6d609(MD5)
8c92d1a569f7263cf4485812366e66e3b503a2f5(SHA1) Length of CTL file: 4947
The CTL File was last modified on Fri Mar 06 19:45:13 CET 2015 [...]
CTL Record #:1 ----
BYTEPOS TAG LENGTH VALUE --- --- --- --- 1 RECORDLENGTH 2 1156
2 DNSNAME 16 cucm-1051-a-pub
3 SUBJECTNAME 62 CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
ST=Malopolska;C=PL
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 62 CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
ST=Malopolska;C=PL
6 SERIALNUMBER 16 70:CA:F6:4E:09:07:51:B9:DF:22:F4:9F:75:4F:C5:BB 7 PUBLICKEY 140
8 SIGNATURE 128
9 CERTIFICATE 694 E9 D4 33 64 5B C8 8C ED 51 4D 8F E5 EA 5B 6D 21 A5 A3 8C 9C (SHA1 Hash HEX)
10 IPADDRESS 4
This etoken was used to sign the CTL file.
●
CTL-Client - Wenn diese Methode verwendet wird, wird Ihre CTL-Datei mit einem der Hardware-eToken signiert.
admin:show ctl
The checksum value of the CTL file:
●
256a661f4630cd86ef460db5aad4e91c(MD5)
3d56cc01476000686f007aac6c278ed9059fc124(SHA1) Length of CTL file: 5728
The CTL File was last modified on Fri Mar 06 21:48:48 CET 2015 [...]
CTL Record #:5 ----
BYTEPOS TAG LENGTH VALUE --- --- --- --- 1 RECORDLENGTH 2 1186 2 DNSNAME 1
3 SUBJECTNAME 56 cn="SAST-ADN008580ef ";ou=IPCBU;o="Cisco Systems 4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 42 cn=Cisco Manufacturing CA;o=Cisco Systems 6 SERIALNUMBER 10 83:E9:08:00:00:00:55:45:AF:31
7 PUBLICKEY 140
9 CERTIFICATE 902 85 CD 5D AD EA FC 34 B8 3E 2F F2 CB 9C 76 B0 93 3E 8B 3A 4F (SHA1 Hash HEX)
10 IPADDRESS 4
This etoken was used to sign the CTL file.
Hinweis: Sie können zwischen der Methode wechseln, die im gemischten CUCM-Modus mit Tokenless CTL verwendet wird.
Abhängig von der Methode zur Sicherung Ihres Clusters muss ein geeignetes CTL-
Aktualisierungsverfahren angewendet werden. Führen Sie entweder den CTL-Client erneut aus, oder geben Sie den Befehl utils ctl update CTLfile über die CLI ein.
Standardmäßige Überprüfung der Sicherheit im Cluster
Die Vermeidung von ITL-Problemen ist wichtig, da dies zu einem Ausfall vieler Funktionen führen kann oder das Telefon sich weigert, sich an Konfigurationsänderungen zu halten. ITL-Probleme können auf zwei Arten vermieden werden.
Verwenden des Prepare-Clusters für die Funktion "Rollback to pre 8.0"
Dank dieser Funktion wird Ihre ITL auf allen Servern gelöscht, sodass die Telefone jedem TFTP- Server vertrauen. Telefondienste (z. B. Durchwahlmobilität) funktionieren nicht, wenn dieser Parameter auf True festgelegt ist. Sie können jedoch weiterhin einfache Telefonanrufe tätigen und empfangen.
Hinweis: Eine Änderung dieses Parameters bewirkt, dass ALLE TELEFONE ZURÜCKGESETZT WERDEN.
Sobald diese Funktion eingerichtet ist, müssen alle TFTP-Server neu gestartet werden (um die neue ITL bereitzustellen), und alle Telefone müssen zurückgesetzt werden, damit sie die neue leere ITL anfordern können. Nachdem die Zertifikatsänderungen abgeschlossen und alle erforderlichen Dienste neu gestartet wurden, kann diese Funktion auf False zurückgesetzt, der TFTP-Dienst neu gestartet und das Telefon zurückgesetzt werden (sodass das Telefon die gültige ITL-Datei abrufen kann). Alle Funktionen funktionieren weiterhin wie zuvor.
Regenerieren von Zertifikaten in einer bestimmten Bestellung
Bei diesem Verfahren wird einem TFTP-Server eine gültige/aktualisierte ITL-Datei von einem vertrauenswürdigen TFTP-Server bereitgestellt, der verfügbar ist.
Beenden Sie den TFTP-Dienst auf dem primären TFTP-Server.
1.
Nehmen Sie ggf. Änderungen an den Zertifikaten des primären TFTP-Servers vor.
2.
Setzen Sie die Telefone zurück (um eine neue ITL-Datei vom sekundären TFTP-Server zu erhalten) - abhängig davon, welche Zertifikate neu generiert werden, kann dies automatisch passieren.
3.
Sobald die Telefone zurückgegeben wurden, starten Sie den TFTP-Dienst des primären TFTP-Servers.
4.
Nehmen Sie Zertifikatänderungen auf dem sekundären TFTP-Server vor.
5.
Setzen Sie die Telefone zurück (um eine neue ITL-Datei vom primären TFTP-Server zu erhalten).
6.
Vorsicht: Bearbeiten Sie KEINE Zertifikate auf beiden TFTP-Servern gleichzeitig. Dadurch wird den Telefonen kein TFTP-Server vertrauenswürdig, und der lokale Administrator muss die ITL von allen Telefonen manuell entfernen.
Entfernen und Neuerstellen von Zertifikaten in CUCM
Es können nur Service-Zertifikate (Zertifikatsspeicher, die nicht mit "-trust" gekennzeichnet sind) regeneriert werden. Zertifikate in den Vertrauensspeichern (Zertifikatspeicher, die mit "-trust"
gekennzeichnet sind) müssen gelöscht werden, da sie nicht neu generiert werden können.
Vorsicht: Beachten Sie die Cisco Bug-ID CSCut58407 - Geräte sollten nicht neu gestartet werden, wenn CAPF/CallManager/TVS-trust entfernt wird.
Nach allen Zertifikatsänderungen muss der entsprechende Service neu gestartet werden, um die Änderung zu übernehmen. Dies wird im Abschnitt Nach Neuerstellung/Entfernen von Zertifikaten behandelt.
Vorsicht: Beachten Sie, dass die Cisco Bug-ID CSCto86463 - Gelöschte Zertifikate wieder angezeigt werden, Zertifikate nicht aus dem CUCM entfernen können. Dies ist ein Problem, bei dem gelöschte Zertifikate nach dem Entfernen weiterhin wieder erscheinen. Folgen Sie der Behebung des Fehlers.
Regenerieren von Zertifikaten über die CLI
Vorsicht: Die Regeneration von Zertifikaten löst eine automatische Aktualisierung der ITL-
Dateien im Cluster aus. Dies löst einen clusterweiten Softphone-Reset aus, damit Telefone eine Aktualisierung ihrer lokalen ITL auslösen können. Der Schwerpunkt liegt dabei auf der Generierung von Zertifikaten für CAPF und CallManager, kann aber auch mit anderen Zertifikatsspeichern innerhalb des CUCM auftreten, z. B. Tomcat.
Regeneriert CAPF: Nach der Regeneration lädt sich das CAPF-Zertifikat automatisch selbst in CAPF-trust und CallManager-trust hoch. Außerdem verfügt CAPF immer über einen eindeutigen Betreffnamen-Header. Daher werden zuvor verwendete CAPF-Zertifikate beibehalten und für die Authentifizierung verwendet.
set cert regen CAPF
Hinweis: Wenn ein CAPF-Zertifikat abgelaufen ist, können sich Telefone, die LSC
verwenden, nicht beim CUCM registrieren, da CUCM ihr Zertifikat zurückweist. Sie können jedoch auch mit dem neuen CAPF-Zertifikat eine neue LSC für das Telefon erstellen. Wenn Sie das Telefon neu starten, lädt es die Konfiguration herunter und kontaktiert dann CAPF, um LSC zu aktualisieren. Nach der Aktualisierung von LSC wird das Telefon so registriert, wie es sollte. Dies funktioniert, solange sich ein neues CAPF-Zertifikat in der ITL-Datei befindet und das Telefon das Zertifikat heruntergeladen hat und dem es vertraut ist (callmanager.pem).
Neuerstellen von CallManager: Nach der Wiederherstellung lädt sich der CallManager automatisch selbst in CallManager-Vertrauenswürdigkeit hoch.
set cert regen CallManager
Regeneriert IPsec: Nach der Regeneration lädt sich das IPsec-Zertifikat automatisch in ipsec-trust hoch.
set cert regen ipsec
Regeneriert Tomcat: Nach der Wiederherstellung lädt sich das Tomcat-Zertifikat automatisch in tomcat-trust hoch.
set cert regen tomcat
Regeneriert TVS:
set cert regen TVS
Was ist zu erwarten?
Wenn Sie Zertifikate über die CLI neu generieren, werden Sie aufgefordert, diese Änderung zu überprüfen. Geben Sie yes ein und klicken Sie auf Enter.
admin:set cert regen CAPF
WARNING: This operation will overwrite any CA signed certificate previously imported for CAPF
Proceed with regeneration (yes|no)? yes
Successfully Regenerated Certificate for CAPF.
You must restart services related to CAPF for the regenerated certificates to become active.
Entfernen von Zertifikaten über die CLI
Entfernen von CAPF-Vertrauenszertifikaten
set cert delete CAPF <name of certificate>.pem
Entfernen von Zertifikaten der CallManager-Vertrauenswürdigkeit
set cert delete CallManager <name of certificate>.pem
Entfernen von ipsec-trust-Zertifikaten
set cert delete ipsec <name of certificate>.pem
Entfernen Sie Tomcat-Vertrauenszertifikate.
set cert delete tomcat <name of certificate>.pem
Entfernen von TVS-Vertrauenszertifikaten
set cert delete TVS <name of certificate>.pem
Regenerieren von Zertifikaten über die Web-GUI
Regeneriert CAPF:
Nach der Regeneration lädt sich das CAPF-Zertifikat automatisch selbst in CAPF-trust und CallManager-trust hoch. Außerdem verfügt das CAPF-Zertifikat immer über einen eindeutigen Betreffnamen-Header. Daher werden zuvor verwendete CAPF-Zertifikate beibehalten und für die Authentifizierung verwendet.
OS Admin > Security > Certificate Management > Find > Click CAPF certificate > Regenerate
Neuerstellen von CallManager:
Nach der Wiederherstellung lädt sich das CallManager-Zertifikat automatisch selbst in CallManager-Vertrauenswürdigkeit hoch.
OS Admin > Security > Certificate Management > Find > Click CallManager certificate > Regenerate
Regeneriert IPsec:
Nach der Regeneration lädt sich das IPsec-Zertifikat automatisch in ipsec-trust hoch.
OS Admin > Security > Certificate Management > Find > Click ipsec certificate > Regenerate
Regeneriert Tomcat:
Nach der Wiederherstellung lädt sich das Tomcat-Zertifikat automatisch in tomcat-trust hoch.
OS Admin > Security > Certificate Management > Find > Click tomcat certificate > Regenerate
Regeneriert TVS:
OS Admin > Security > Certificate Management > Find > Click TVS certificate > Regenerate
Entfernen von Zertifikaten über die Web-GUI
OS Admin > Security > Certificate Management > Find > Click X certificate within the '-trust' store > Remove/Delete
Nach der Regeneration/Entfernung von Zertifikaten
Nachdem Sie ein Zertifikat aus einem Zertifikatsspeicher entfernt oder neu generiert haben, muss der entsprechende Service neu gestartet werden, um die Änderung übernehmen zu können.
Geschäft Service zum Neustart Wie Tomate Tomate
CLI: utils service restart Cisco Tomcat
Befolgen Sie ggf. die erforderlichen Schritte aus der CCX-Umgebung.
https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/118855-configure-uccx-00.html#anc12
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_12_5/release/guide/uccx_b_uccx-solution-release-notes-125/uccx_b_uccx-solution-release-notes-125_chapter_01.html#reference_2D9122E01C43B6E0AA06AB2A3248B797 CallManager
CallManager;
TFTP;
CTIManager
Web-GUI: Navigieren Sie zu Cisco Unified Serviceability > Tools > Control Center - Feature Services > (Server auswählen). Klicken Sie unter Cisco CallManager auf Neu starten.
Web-Benutzeroberfläche: Navigieren Sie zu Cisco Unified Serviceability > Tools > Control Center - Feature Services > (Server auswählen). Klicken Sie unter Cisco TFTP auf Neustart.
Web-Benutzeroberfläche: Navigieren Sie zu Cisco Unified Serviceability > Tools > Control Center - Feature Services > (Server auswählen). Klicken Sie unter Cisco CTIManager auf Neu starten.
CAPF
CAPF (nur bei
Publisher)
Web-GUI: Navigieren Sie zu Cisco Unified Serviceability > Tools > Control Center - Feature Services > (Server auswählen). Klicken Sie unter Cisco Certificate Authority Proxy Function auf Neu starten.
TVS
Trust Verification Service (auf dem
jeweiligen Server)
Web-GUI: Navigieren Sie zu Cisco Unified Serviceability > Tools > Control Center - Network Services > (Select Server). Klicken Sie unter Cisco Trust Verification Service auf Neustart.
IPS
Cisco DRF Local (auf allen Knoten);
Cisco DRF Master (auf Publisher)
CLI: utils service restart Cisco DRF Local CLI: utils service restart Cisco DRF Master
Installieren/Aktualisieren von LSC auf dem Telefon
Wenn das CAPF-Zertifikat regeneriert wurde, müssen die LSC-Zertifikate für alle Telefone im Cluster mit dem vom neuen CAPF-Zertifikat signierten LSC aktualisiert werden.
Navigieren Sie zu CUCM Serviceability > Service Activation. Aktivieren Sie die Cisco CTL- 1.
Anbieter- und die Cisco Certificate Authority Proxy-Funktion auf dem Publisher-Server.
Navigieren Sie unter CUCM CCMAdmin zu Gerät > Telefon. Wählen Sie das IP-Telefon aus, für das Sie ein LSC bereitstellen möchten.
2.
Navigieren Sie auf der Seite Device Configuration (Gerätekonfiguration) unter Certificate Operation (Zertifikatvorgang) zu Install/Upgrade > By Null String.
3.
Speichern Sie die Telefonkonfiguration in CCMAdmin, und wählen Sie Apply Config (Konfiguration anwenden).
4.
Wenn das Telefon Probleme mit der Installation des LSC hat, führen Sie die folgenden Schritte am Telefon aus:
Wenn das Telefon zurückgesetzt wird, navigieren Sie unter dem physischen Telefon zu Einstellungen > (6) Sicherheitskonfiguration > (4) LSC > **# (dieser Vorgang entsperrt die
Benutzeroberfläche und ermöglicht es uns, mit dem nächsten Schritt fortzufahren) > Aktualisieren (die Aktualisierung wird erst angezeigt, wenn Sie den vorherigen Schritt ausgeführt haben).
Klicken Sie jetzt auf Senden.
Weisen Sie einem Telefon nur Zertifikate zu, wenn es sich um ein Wireless-Telefon handelt (7921/25). Wireless-Telefone verwenden Zertifizierungsstellen von Drittanbietern (Certificate Authority, CA), um sich zu authentifizieren.
Schlussfolgerung
Wenn bei diesem Verfahren ein Problem auftritt oder Hilfe benötigt wird, wenden Sie sich an das Cisco Technical Assistance Center (TAC), um Hilfe zu erhalten. Halten Sie in diesem Fall Ihre DRF-Sicherung verfügbar, da sie als letzter Ausweg verwendet wird, um den Dienst
wiederherzustellen, wenn TAC dies nicht über andere Methoden tun kann.
