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 SBD-Funktion (Security By Default) von Cisco Unified Communications Manager (CUCM) Version 8.0 und höher beschrieben.
In CUCM Version 8.0 und höher wird die SBD-Funktion eingeführt, die aus ITL-Dateien (Identity Trust List) und dem Trust Verification Service (TVS) besteht.
Alle CUCM-Cluster verwenden jetzt automatisch ITL-basierte Sicherheit. Es besteht ein Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit/Benutzerfreundlichkeit, den Administratoren beachten müssen, bevor sie bestimmte Änderungen an einem CUCM-Cluster der Version 8.0 vornehmen.
Dieses Dokument dient als Ergänzung zu den offiziellen Standarddokumenten für Sicherheit und enthält betriebliche Informationen und Tipps zur Fehlerbehebung, die Administratoren helfen und die Fehlerbehebung vereinfachen.
Es ist eine gute Idee, mit diesen Kernkonzepten von SBD vertraut zu werden: Asymmetric Key Cryptography Wikipedia Artikel und Public Key Infrastructure Wikipedia Artikel.
Dieser Abschnitt bietet einen kurzen Überblick über die Funktionen von SBD. Vollständige technische Details der einzelnen Funktionen finden Sie im Abschnitt SBD-Details und Informationen zur Fehlerbehebung.
SBD bietet die folgenden drei Funktionen für unterstützte IP-Telefone:
Dieses Dokument bietet einen Überblick über die einzelnen Funktionen.
Wenn eine CTL- (Certificate Trust List) oder ITL-Datei vorhanden ist, fordert das IP-Telefon eine signierte TFTP-Konfigurationsdatei vom CUCM-TFTP-Server an.
Mit dieser Datei kann das Telefon überprüfen, ob die Konfigurationsdatei von einer vertrauenswürdigen Quelle stammt. Wenn CTL-/ITL-Dateien auf Telefonen vorhanden sind, müssen Konfigurationsdateien von einem vertrauenswürdigen TFTP-Server signiert werden.
Die Datei befindet sich während der Übertragung im Klartext im Netzwerk, wird jedoch mit einer speziellen Verifizierungssignatur ausgeliefert.
Das Telefon fordert SEP<MAC-Adresse>.cnf.xml.sgn an, um die Konfigurationsdatei mit der speziellen Signatur zu erhalten.
Diese Konfigurationsdatei wird vom privaten TFTP-Schlüssel signiert, der CallManager.pem auf der Seite "Operating System (OS) Administration Certificate Management" (Zertifikatsverwaltung für Betriebssystem) entspricht.
Die signierte Datei hat eine Signatur an der Spitze, um die Datei zu authentifizieren, ist aber ansonsten in Klartext-XML.
Das folgende Bild zeigt, dass der Signierer der Konfigurationsdatei CN=CUCM8-Publisher.bbburns.lab ist, die wiederum von CN=JASBURNS-AD signiert wird.
Das bedeutet, dass das Telefon die Signatur von CUCM8-Publisher.bbburns.lab anhand der ITL-Datei überprüfen muss, bevor diese Konfigurationsdatei akzeptiert wird.
Im folgenden Diagramm wird dargestellt, wie der private Schlüssel zusammen mit einer Message Digest Algorithm (MD)5- oder Secure Hash Algorithm (SHA)1-Hashfunktion verwendet wird, um die signierte Datei zu erstellen.
Bei der Signaturüberprüfung wird dieser Prozess durch die Verwendung des öffentlichen Schlüssels rückgängig gemacht, der zum Entschlüsseln des Hashs passt. Wenn die Hashes übereinstimmen, wird Folgendes angezeigt:
Wenn die optionale TFTP-Konfigurationsverschlüsselung im zugeordneten Telefonsicherheitsprofil aktiviert ist, fordert das Telefon eine verschlüsselte Konfigurationsdatei an.
Diese Datei wird mit dem privaten TFTP-Schlüssel signiert und mit einem symmetrischen Schlüssel verschlüsselt, der zwischen dem Telefon und dem CUCM ausgetauscht wird (vollständige Details finden Sie im Cisco Unified Communications Manager Security Guide, Release 8.5(1)).
Sein Inhalt kann mit einem Netzwerk-Sniffer nur gelesen werden, wenn der Beobachter über die notwendigen Schlüssel verfügt.
Das Telefon fordert SEP<MAC-Adresse>.cnf.xml.enc.sgn an, um die signierte verschlüsselte Datei abzurufen.
Die verschlüsselte Konfigurationsdatei hat die Signatur auch am Anfang, aber es gibt keine Klartextdaten nach, nur verschlüsselte Daten (verworrene Binärzeichen in diesem Texteditor).
Das Bild zeigt, dass der Signierer derselbe ist wie im vorherigen Beispiel, daher muss dieser Signierer in der ITL-Datei vorhanden sein, bevor das Telefon die Datei akzeptiert.
Außerdem müssen die Entschlüsselungsschlüssel korrekt sein, bevor das Telefon den Inhalt der Datei lesen kann.
IP-Telefone verfügen über einen begrenzten Arbeitsspeicher und können darüber hinaus eine große Anzahl von Telefonen in einem Netzwerk verwalten.
Der CUCM fungiert über den TVS als Remote-Vertrauensspeicher, sodass nicht auf jedem IP-Telefon ein vollständiger Zertifikatvertrauensspeicher platziert werden muss.
Wenn das Telefon eine Signatur oder ein Zertifikat nicht über die CTL- oder ITL-Dateien überprüfen kann, wird der TVS-Server zur Überprüfung aufgefordert.
Dieser zentrale Vertrauensspeicher ist einfacher zu verwalten, als wenn er auf allen IP-Telefonen vorhanden wäre.
In diesem Abschnitt wird der SBD-Prozess im Detail beschrieben.
Zunächst müssen einige Dateien auf dem CUCM-Server selbst vorhanden sein. Der wichtigste Bestandteil ist das TFTP-Zertifikat und der private TFTP-Schlüssel.
Das TFTP-Zertifikat finden Sie unter Betriebssystem-Verwaltung > Sicherheit > Zertifikats-Management > CallManager.pem.
Der CUCM-Server verwendet den privaten und den öffentlichen Schlüssel des Zertifikats CallManager.pem für den TFTP-Dienst (sowie für den Cisco Call Manager (CCM)-Dienst).
Das Bild zeigt, dass das Zertifikat CallManager.pem für CUCM8-publisher.bbburns.lab ausgestellt und von JASBURNS-AD signiert wird. Alle TFTP-Konfigurationsdateien werden mit dem unten angegebenen privaten Schlüssel signiert.
Alle Telefone können den öffentlichen TFTP-Schlüssel im Zertifikat CallManager.pem verwenden, um alle mit dem privaten TFTP-Schlüssel verschlüsselten Dateien zu entschlüsseln und alle mit dem privaten TFTP-Schlüssel signierten Dateien zu überprüfen.
Zusätzlich zum privaten Schlüssel für das Zertifikat CallManager.pem speichert der CUCM-Server auch eine ITL-Datei, die den Telefonen angezeigt wird.
Der Befehl show itl zeigt den vollständigen Inhalt dieser ITL-Datei über SSH (Secure Shell)-Zugriff auf die Betriebssystem-CLI des CUCM-Servers an.
In diesem Abschnitt wird die ITL-Datei Stück für Stück aufgeführt, da sie eine Reihe wichtiger Komponenten enthält, die für das Telefon verwendet werden.
Der erste Teil ist die Signaturinformation. Selbst die ITL-Datei ist eine signierte Datei. Diese Ausgabe zeigt, dass sie vom privaten TFTP-Schlüssel signiert wird, der mit dem vorherigen CallManager.pem-Zertifikat verknüpft ist.
admin:show itl
Length of ITL file: 5438
The ITL File was last modified on Wed Jul 27 10:16:24 EDT 2011
Parse ITL File
----------------
Version: 1.2
HeaderLength: 296 (BYTES)
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
3 SIGNERID 2 110
4 SIGNERNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
5 SERIALNUMBER 10 21:00:2D:17:00:00:00:00:00:05
6 CANAME 15 CN=JASBURNS-AD
*Signature omitted for brevity*
Die nächsten Abschnitte enthalten jeweils ihren Zweck innerhalb eines speziellen Function-Parameters. Die erste Funktion ist das Sicherheitstoken des Systemadministrators. Dies ist die Signatur des öffentlichen TFTP-Schlüssels.
ITL Record #:1
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1972
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 15 CN=JASBURNS-AD
6 SERIALNUMBER 10 21:00:2D:17:00:00:00:00:00:05
7 PUBLICKEY 140
8 SIGNATURE 256
9 CERTIFICATE 1442 0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5
8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)
This etoken was used to sign the ITL file.
Die nächste Funktion ist CCM+TFTP. Dies ist wieder der öffentliche TFTP-Schlüssel, der zum Authentifizieren und Entschlüsseln heruntergeladener TFTP-Konfigurationsdateien dient.
ITL Record #:2
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1972
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 CCM+TFTP
5 ISSUERNAME 15 CN=JASBURNS-AD
6 SERIALNUMBER 10 21:00:2D:17:00:00:00:00:00:05
7 PUBLICKEY 140
8 SIGNATURE 256
9 CERTIFICATE 1442 0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5
8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)
Die nächste Funktion ist TVS. Es gibt einen Eintrag für den öffentlichen Schlüssel jedes TVS-Servers, mit dem das Telefon verbunden ist.
Auf diese Weise kann das Telefon eine SSL-Sitzung (Secure Sockets Layer) mit dem TVS-Server herstellen.
ITL Record #:3
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 743
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6 SERIALNUMBER 8 2E:3E:1A:7B:DA:A6:4D:84
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 C7 E1 D9 7A CC B0 2B C2 A8 B2 90 FB
AA FE 66 5B EC 41 42 5D
12 HASH ALGORITHM 1 SHA-1
Die letzte in der ITL-Datei enthaltene Funktion ist die CAPF (Certificate Authority Proxy Function).
Mit diesem Zertifikat können die Telefone eine sichere Verbindung mit dem CAPF-Dienst auf dem CUCM-Server herstellen, sodass das Telefon ein LSC (Locally Significant Certificate) installieren oder aktualisieren kann.
ITL Record #:4
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 455
2 DNSNAME 2
3 SUBJECTNAME 61 CN=CAPF-9c4cba7d;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 61 CN=CAPF-9c4cba7d;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6 SERIALNUMBER 8 0A:DC:6E:77:42:91:4A:53
7 PUBLICKEY 140
8 SIGNATURE 128
11 CERTHASH 20 C7 3D EA 77 94 5E 06 14 D2 90 B1
A1 43 7B 69 84 1D 2D 85 2E
12 HASH ALGORITHM 1 SHA-1
The ITL file was verified successfully.
Im nächsten Abschnitt wird genau beschrieben, was beim Booten eines Telefons geschieht.
Nachdem das Telefon gestartet wurde und eine IP-Adresse sowie die Adresse eines TFTP-Servers bezieht, werden zuerst die CTL- und die ITL-Dateien angefordert.
Diese Paketerfassung zeigt eine Telefonanfrage für die ITL-Datei. Wenn Sie nach tftp.opcode == 1 filtern, werden alle TFTP-Leseanforderungen vom Telefon angezeigt:
Da das Telefon CTL- und ITL-Dateien erfolgreich vom TFTP empfangen hat, fordert das Telefon eine signierte Konfigurationsdatei an.
Die Protokolle der Telefonkonsole, die dieses Verhalten anzeigen, sind über die Webschnittstelle des Telefons verfügbar:
Zunächst fordert das Telefon eine CTL-Datei an, die erfolgreich ist:
837: NOT 09:13:17.561856 SECD: tlRequestFile: Request CTLSEP0011215A1AE3.tlv
846: NOT 09:13:17.670439 TFTP: [27]:Requesting CTLSEP0011215A1AE3.tlv from
14 . 48 . 44 . 80
847: NOT 09:13:17.685264 TFTP: [27]:Finished --> rcvd 4762 bytes
Als Nächstes fordert das Telefon auch eine ITL-Datei an:
868: NOT 09:13:17.860613 TFTP: [28]:Requesting ITLSEP0011215A1AE3.tlv from
14 . 48 . 44 . 80
869: NOT 09:13:17.875059 TFTP: [28]:Finished --> rcvd 5438 bytes
Nachdem die ITL-Datei heruntergeladen wurde, muss sie überprüft werden. Es gibt eine Reihe von Zuständen, in denen sich ein Telefon zu diesem Zeitpunkt befinden kann. Daher werden diese in diesem Dokument alle Zustände behandelt.
Das folgende Flussdiagramm beschreibt, wie das Telefon signierte Dateien und HTTPS-Zertifikate überprüft:
In diesem Fall kann das Telefon die Signatur in den ITL- und CTL-Dateien überprüfen. Das Telefon verfügt bereits über eine CTL und eine ITL, sodass es einfach mit ihnen abgeglichen und die richtige Signatur gefunden hat.
877: NOT 09:13:17.925249 SECD: validate_file_envelope:
File sign verify SUCCESS; header length <296>
Da das Telefon die CTL- und ITL-Dateien heruntergeladen hat, werden von diesem Zeitpunkt an NUR noch signierte Konfigurationsdateien angefordert.
Dies veranschaulicht, dass die Telefonlogik darauf ausgelegt ist, die Sicherheit des TFTP-Servers auf der Grundlage von CTL und ITL zu ermitteln und dann nach einer signierten Datei zu fragen:
917: NOT 09:13:18.433411 tftpClient: tftp request rcv'd from /usr/tmp/tftp,
srcFile = SEP0011215A1AE3.cnf.xml, dstFile = /usr/ram/SEP0011215A1AE3.cnf.xml
max size = 550001
918: NOT 09:13:18.457949 tftpClient: auth server - tftpList[0] = ::ffff:
14 . 48 . 44 . 80
919: NOT 09:13:18.458937 tftpClient: look up server - 0
920: NOT 09:13:18.462479 SECD: lookupCTL: TFTP SRVR secure
921: NOT 09:13:18.466658 tftpClient: secVal = 0x9 922: NOT 09:13:18.467762
tftpClient: ::ffff:14 . 48 . 44 . 80 is a secure server
923: NOT 09:13:18.468614 tftpClient: retval = SRVR_SECURE
924: NOT 09:13:18.469485 tftpClient: Secure file requested
925: NOT 09:13:18.471217 tftpClient: authenticated file approved - add .sgn
-- SEP0011215A1AE3.cnf.xml.sgn
926: NOT 09:13:18.540562 TFTP: [10]:Requesting SEP0011215A1AE3.cnf.xml.sgn
from 14 . 48 . 44 . 80 with size limit of 550001
927: NOT 09:13:18.559326 TFTP: [10]:Finished --> rcvd 7652 bytes
Sobald die signierte Konfigurationsdatei heruntergeladen wurde, muss sie vom Telefon anhand der Funktion für CCM+TFTP im ITL authentifiziert werden:
937: NOT 09:13:18.656906 SECD: verifyFile: verify SUCCESS
</usr/ram/SEP0011215A1AE3.cnf.xml>
Die ITL-Datei stellt eine TVS-Funktion bereit, die das Zertifikat des TVS-Dienstes enthält, der auf dem TCP-Port 2445 des CUCM-Servers ausgeführt wird.
Der TVS wird auf allen Servern ausgeführt, auf denen der CallManager-Dienst aktiviert ist. Der CUCM-TFTP-Dienst verwendet die konfigurierte CallManager-Gruppe, um eine Liste der TVS-Server zu erstellen, die das Telefon in der Telefonkonfigurationsdatei kontaktieren muss.
In einigen Übungen wird nur ein einziger CUCM-Server verwendet. In einem CUCM-Cluster mit mehreren Knoten können bis zu drei TVS-Einträge für ein Telefon vorhanden sein, einer für jeden CUCM in der CUCM-Gruppe des Telefons.
Dieses Beispiel zeigt, was passiert, wenn die Telefonverzeichnis-Taste am IP-Telefon gedrückt wird. Die Verzeichnisse-URL ist für HTTPS konfiguriert, sodass das Tomcat-Webzertifikat vom Verzeichnisse-Server auf dem Telefon angezeigt wird.
Dieses Tomcat-Webzertifikat (tomcat.pem in der BS-Verwaltung) ist nicht in das Telefon geladen, daher muss sich das Telefon mit dem TVS in Verbindung setzen, um das Zertifikat zu authentifizieren.
Eine Beschreibung der Interaktion finden Sie im vorherigen TVS-Übersichtsdiagramm. Die Protokollperspektive für die Telefonkonsole sieht folgendermaßen aus:
Zuerst finden Sie die Verzeichnis-URL:
1184: NOT 15:20:55.219275 JVM: Startup Module Loader|cip.dir.TandunDirectories:
? - Directory url https://14 . 48 . 44 . 80:8443/ccmcip/xmldirectory.jsp
Es handelt sich um eine sichere SSL/TLS-HTTP-Sitzung (Transport Layer Security), die einer Überprüfung bedarf.
1205: NOT 15:20:59.404971 SECD: clpSetupSsl: Trying to connect to IPV4, IP:
14 . 48 . 44 . 80, Port : 8443
1206: NOT 15:20:59.406896 SECD: clpSetupSsl: TCP connect() waiting,
<14 . 48 . 44 . 80> c:8 s:9 port: 8443
1207: NOT 15:20:59.408136 SECD: clpSetupSsl: TCP connected,
<14 . 48 . 44 . 80> c:8 s:9
1208: NOT 15:20:59.409393 SECD: clpSetupSsl: start SSL/TLS handshake,
<14 . 48 . 44 . 80> c:8 s:9
1209: NOT 15:20:59.423386 SECD: srvr_cert_vfy: Server Certificate
Validation needs to be done
Das Telefon überprüft zunächst, ob das vom SSL/TLS-Server bereitgestellte Zertifikat in der CTL vorhanden ist. Anschließend prüft das Telefon die Funktionen in der ITL-Datei, um festzustellen, ob eine Übereinstimmung gefunden wird.
Diese Fehlermeldung lautet "HTTPS-Zertifikat nicht in CTL", was bedeutet, dass "die Zertifizierung nicht in CTL oder ITL gefunden werden kann".
1213: NOT 15:20:59.429176 SECD: findByCertAndRoleInTL: Searching TL from CTL file
1214: NOT 15:20:59.430315 SECD: findByCertAndRoleInTL: Searching TL from ITL file
1215: ERR 15:20:59.431314 SECD: EROR:https_cert_vfy: HTTPS cert not in CTL,
<14 . 48 . 44 . 80>
Nachdem der direkte Inhalt der CTL- und ITL-Datei auf das Zertifikat überprüft wurde, wird als Nächstes der TVS-Cache vom Telefon überprüft.
Dies dient dazu, den Netzwerkverkehr zu reduzieren, wenn das Telefon kürzlich den TVS-Server nach dem gleichen Zertifikat gefragt hat.
Wenn das HTTPS-Zertifikat nicht im Telefoncache gefunden wird, können Sie eine TCP-Verbindung zum TVS-Server selbst herstellen.
1220: NOT 15:20:59.444517 SECD: processTvsClntReq: TVS Certificate
Authentication request
1221: NOT 15:20:59.445507 SECD: lookupAuthCertTvsCacheEntry: No matching
entry found at cache
1222: NOT 15:20:59.446518 SECD: processTvsClntReq: No server sock exists,
must be created
1223: NOT 15:20:59.451378 SECD: secReq_initClient: clnt sock fd 11 bound
to </tmp/secClnt_secd>
1224: NOT 15:20:59.457643 SECD: getTvsServerInfo: Phone in IPv4 only mode
1225: NOT 15:20:59.458706 SECD: getTvsServerInfo: Retreiving IPv4 address
1230: NOT 15:20:59.472628 SECD: connectToTvsServer: Successfully started
a TLS connection establishment to the TVS server: IP:14 . 48 . 44 . 80, port:2445
(default); Waiting for it to get connected.
Denken Sie daran, dass die Verbindung zum TVS selbst SSL/TLS (Secure HTTP oder HTTPS) ist. Es handelt sich also auch um ein Zertifikat, das gegenüber der CTL gegenüber ITL authentifiziert werden muss.
Wenn alles richtig läuft, befindet sich das TVS-Serverzertifikat in der TVS-Funktion der ITL-Datei. Siehe ITL-Datensatz #3 im vorherigen Beispiel der ITL-Datei.
1244: NOT 15:20:59.529938 SECD: srvr_cert_vfy: Server Certificate Validation
needs to be done
1245: NOT 15:20:59.533412 SECD: findByIssuerAndSerialAndRoleInTL:
Searching TL from CTL file
1246: NOT 15:20:59.534936 SECD: findByIssuerAndSerialAndRoleInTL:
Searching TL from ITL file
1247: NOT 15:20:59.537359 SECD: verifyCertWithHashFromTL: cert hash and
hash in TL MATCH
1248: NOT 15:20:59.538726 SECD: tvs_cert_vfy: TVS cert verified with hash
from TL, <14 . 48 . 44 . 80>
Erfolg Das Telefon verfügt nun über eine sichere Verbindung zum TVS-Server. Der nächste Schritt besteht darin, den TVS-Server zu fragen: "Hallo, vertraue ich diesem Directory-Serverzertifikat?"
Dieses Beispiel zeigt die Antwort auf diese Frage - eine Antwort von 0 bedeutet Erfolg (kein Fehler).
1264: NOT 15:20:59.789738 SECD: sendTvsClientReqToSrvr: Authenticate
Certificate : request sent to TVS server - waiting for response
1273: NOT 15:20:59.825648 SECD: processTvsSrvrResponse: Authentication Response
received, status : 0
Da eine erfolgreiche Antwort vom TVS vorliegt, werden die Ergebnisse für dieses Zertifikat im Cache gespeichert.
Wenn Sie also innerhalb der nächsten 86.400 Sekunden erneut die Taste Directories (Verzeichnisse) drücken, müssen Sie sich nicht an den TVS-Server wenden, um das Zertifikat zu verifizieren. Sie können einfach auf den lokalen Cache zugreifen.
1279: NOT 15:20:59.837086 SECD: saveCertToTvsCache: Saving certificate
in TVS cache with default time-to-live value: 86400 seconds
1287: ERR 15:20:59.859993 SECD: Authenticated the HTTPS conn via TVS
Überprüfen Sie abschließend, ob die Verbindung zum Verzeichnisserver erfolgreich war.
1302: ERR 15:21:01.959700 JVM: Startup Module Loader|cip.http.ae:?
- listener.httpSucceed: https://14 . 48 . 44 . 80:8443/ccmcip/
xmldirectoryinput.jsp?name=SEP0011215A1AE3
Das nachfolgende Beispiel zeigt, was auf dem CUCM-Server geschieht, auf dem der TVS ausgeführt wird. TVS-Protokolle können mit dem Cisco Unified Real-Time Monitoring Tool (RTMT) erfasst werden.
Die CUCM-TVS-Protokolle zeigen an, dass Sie einen SSL-Handshake mit dem Telefon durchführen, das Telefon fragt TVS nach dem Tomcat-Zertifikat, und TVS antwortet, um anzugeben, dass das Zertifikat im TVS-Zertifikatspeicher übereinstimmt.
15:21:01.954 | debug 14 . 48 . 44 . 202: tvsSSLHandShake Session ciphers - AES256-SHA
15:21:01.954 | debug TLS HS Done for ph_conn .
15:21:02.010 | debug MsgType : TVS_MSG_CERT_VERIFICATION_REQ
15:21:02.011 | debug tvsGetIssuerNameFromX509 - issuerName : CN=CUCM8-
Publisher.bbbburns.lab;OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US and Length: 75
15:21:02.011 | debug CertificateDBCache::getCertificateInformation -
Certificate compare return =0
15:21:02.011 | debug CertificateDBCache::getCertificateInformation -
Certificate found and equal
15:21:02.011 | debug MsgType : TVS_MSG_CERT_VERIFICATION_RES
Der TVS-Zertifikatspeicher ist eine Liste aller Zertifikate, die auf der Webseite Betriebssystemverwaltung > Zertifikatsverwaltung enthalten sind.
Ein häufiges Missverständnis während der Fehlerbehebung betrifft die Tendenz, die ITL-Datei mit der Hoffnung zu löschen, dass sie ein Problem mit der Dateiverifizierung löst.
Manchmal ist das Löschen der ITL-Datei erforderlich, aber die ITL-Datei muss nur gelöscht werden, wenn ALLE diese Bedingungen erfüllt sind.
Hier ist, wie Sie die ersten beiden dieser Bedingungen überprüfen.
Zuerst können Sie die Prüfsumme der auf dem CUCM vorhandenen ITL-Datei mit der Prüfsumme der ITL-Datei des Telefons vergleichen.
Es gibt derzeit keine Möglichkeit, die MD5sum der ITL-Datei auf dem CUCM selbst zu betrachten, bis Sie eine Version mit dem Fix für diesen Cisco Bug CSCto60209 ausführen.
Führen Sie den Vorgang in der Zwischenzeit mit Ihren bevorzugten GUI- oder CLI-Programmen aus:
jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ tftp 14 . 48 . 44 . 80
tftp> get ITLSEP0011215A1AE3.tlv
Received 5438 bytes in 0.0 seconds
tftp> quit
jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ md5sum
ITLSEP0011215A1AE3.tlv
b61910bb01d8d3a1c1b36526cc9f2ddc ITLSEP0011215A1AE3.tlv
Dies zeigt, dass die MD5-Summe der ITL-Datei in CUCM b61910bb01d8d3a1c1b36526cc9f2ddc ist.
Nun können Sie das Telefon selbst betrachten, um den Hash der dort geladenen ITL-Datei zu bestimmen: Einstellungen > Sicherheitskonfiguration > Vertrauensliste.
Dies zeigt, dass die MD5-Summen übereinstimmen. Dies bedeutet, dass die ITL-Datei auf dem Telefon mit der Datei auf dem CUCM übereinstimmt, sodass sie nicht gelöscht werden muss.
Wenn sie übereinstimmt, müssen Sie mit dem nächsten Vorgang fortfahren - bestimmen Sie, ob das TVS-Zertifikat im ITL mit dem vom TVS vorgelegten Zertifikat übereinstimmt. Dieser Vorgang ist etwas komplizierter.
Sehen Sie sich zunächst die Paketerfassung des Telefons an, das mit dem TVS-Server an TCP-Port 2445 verbunden ist.
Klicken Sie in Wireshark mit der rechten Maustaste auf ein beliebiges Paket in diesem Stream, klicken Sie auf Decode As, und wählen Sie SSL aus. Suchen Sie nach dem Serverzertifikat, das wie folgt aussieht:
Sehen Sie sich das TVS-Zertifikat in der vorherigen ITL-Datei an. Dann sehen Sie einen Eintrag mit der Seriennummer 2E3E1A7BDAA64D84.
admin:show itl
ITL Record #:3
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 743
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6 SERIALNUMBER 8 2E:3E:1A:7B:DA:A6:4D:84
Erfolg, die Datei TVS.pem innerhalb der ITL-Datei stimmt mit dem TVS-Zertifikat überein, das im Netzwerk präsentiert wird. Sie müssen die ITL nicht löschen, und der TVS zeigt das richtige Zertifikat an.
Wenn die Dateiauthentifizierung weiterhin fehlschlägt, überprüfen Sie den Rest des vorherigen Flussdiagramms.
Das wichtigste Zertifikat ist jetzt das Zertifikat CallManager.pem. Dieser private Zertifikatschlüssel wird zum Signieren aller TFTP-Konfigurationsdateien verwendet, die die ITL-Datei enthalten.
Wenn die Datei CallManager.pem neu generiert wird, wird ein neues CCM+TFTP-Zertifikat mit einem neuen privaten Schlüssel generiert. Außerdem ist die ITL-Datei jetzt mit diesem neuen CCM+TFTP-Schlüssel signiert.
Wenn Sie CallManager.pem neu generieren und den TVS- und TFTP-Dienst neu starten, geschieht dies beim Starten eines Telefons.
Hinweis: Dieser Teil ist extrem wichtig. Das TVS-Zertifikat aus der alten ITL-Datei muss weiterhin übereinstimmen. Wenn sowohl CallManager.pem als auch TVS.pem genau zur gleichen Zeit neu generiert werden, können die Telefone keine neuen Dateien herunterladen, ohne die ITL manuell vom Telefon zu löschen.
Wichtigste Punkte:
Wenn Sie Telefone mit vorhandenen ITLs von einem Cluster in einen anderen verschieben, müssen der private ITL- und TFTP-Schlüssel berücksichtigt werden.
Jede neue Konfigurationsdatei, die dem Telefon präsentiert wird, MUSS mit einer Signatur in CTL, ITL oder einer Signatur im aktuellen TVS-Telefondienst übereinstimmen.
In diesem Dokument wird erläutert, wie Sie sicherstellen, dass die neue Cluster-ITL-Datei und die Konfigurationsdateien von der aktuellen ITL-Datei auf dem Telefon als vertrauenswürdig eingestuft werden können. https://supportforums.cisco.com/docs/DOC-15799.
Das Zertifikat "CallManager.pem" und der private Schlüssel werden über das Disaster Recovery System (DRS) gesichert. Wenn ein TFTP-Server neu erstellt wird, MUSS er aus dem Backup wiederhergestellt werden, damit der private Schlüssel wiederhergestellt werden kann.
Ohne den privaten Schlüssel CallManager.pem auf dem Server vertrauen Telefone mit aktuellen ITLs, die den alten Schlüssel verwenden, nicht den signierten Konfigurationsdateien.
Wenn ein Cluster neu erstellt und nicht aus der Sicherung wiederhergestellt wird, entspricht dies genau dem Dokument "Telefone zwischen Clustern verschieben". Dies liegt daran, dass ein Cluster mit einem neuen Schlüssel für die Telefone ein anderer Cluster ist.
Es liegt ein schwerwiegender Fehler bei Backup und Wiederherstellung vor. Wenn ein Cluster für die Cisco Bug-ID CSCtn50405 empfänglich ist, enthalten die DRS-Sicherungen nicht das Zertifikat CallManager.pem.
Dadurch erzeugt jeder aus dieser Sicherung wiederhergestellte Server beschädigte ITL-Dateien, bis eine neue CallManager.pem-Datei generiert wird.
Wenn es keine anderen funktionalen TFTP-Server gibt, die den Sicherungs- und Wiederherstellungsvorgang nicht durchlaufen haben, bedeutet dies möglicherweise, dass alle ITL-Dateien von den Telefonen gelöscht werden müssen.
Um zu überprüfen, ob Ihre Datei CallManager.pem neu generiert werden muss, geben Sie den Befehl show itl gefolgt von:
run sql select c.subjectname, c.serialnumber, c.ipv4address, t.name from
certificate as c, certificatetrustrolemap as r, typetrustrole as t where c.pkid =
r.fkcertificate and t.enum = r.tktrustrole
In der ITL-Ausgabe sind folgende Hauptfehler zu suchen:
This etoken was not used to sign the ITL file.
und
Verification of the ITL file failed.
Error parsing the ITL file!!
Die vorherige SQL-Abfrage (Structured Query Language) sucht nach Zertifikaten, die die Rolle "Authentication and Authorization" haben.
Das Zertifikat "CallManager.pem" in der vorherigen Datenbankabfrage, das die Rolle "Authentication and Authorization" (Authentifizierung und Autorisierung) hat, muss auch auf der Webseite "OS Administration Certificate Management" (Zertifikatsverwaltung für die Betriebssystemverwaltung) vorhanden sein.
Wenn der vorherige Fehler auftritt, besteht eine Diskrepanz zwischen den Zertifikaten von CallManager.pem in der Abfrage und auf der Betriebssystem-Webseite.
Wenn Sie den Hostnamen oder den Domänennamen eines CUCM-Servers ändern, werden alle Zertifikate auf diesem Server auf einmal neu generiert. Im Abschnitt zur Zertifikaterneuerung wurde erklärt, dass die Regeneration sowohl von TVS.pem als auch von CallManager.pem eine "schlechte Sache" ist.
Es gibt einige Szenarien, in denen eine Änderung des Hostnamens fehlschlägt, und einige, in denen sie problemlos funktioniert. In diesem Abschnitt werden alle Aspekte behandelt und sie mit dem verknüpft, was Ihnen bereits aus diesem Dokument über TVS und ITL bekannt ist.
Cluster mit einem Knoten und nur ITL (Vorsicht, keine Vorbereitung)
Cluster mit einem Knoten und CTL und ITL (kann vorübergehend unterbrochen, aber leicht behoben werden)
Cluster mit mehreren Knoten und nur ITL (dies funktioniert in der Regel, kann jedoch bei übereiltem Betrieb dauerhaft unterbrochen werden)
Multi-Node-Cluster mit CTL und ITL (kann nicht dauerhaft unterbrochen werden)
Beim Start eines Telefons mit einer ITL werden folgende Dateien angefordert: CTLSEP<MAC-Adresse>.tlv, ITLSEP<MAC-Adresse>.tlv und SEP<MAC-Adresse>.cnf.xml.sgn.
Wenn das Telefon diese Dateien nicht finden kann, fordert es ITLFile.tlv und CTLFile.tlv an, die ein zentralisierter TFTP-Server für jedes Telefon bereitstellt, das diese anfordert.
Mit zentralisiertem TFTP gibt es einen einzelnen TFTP-Cluster, der auf eine Reihe anderer untergeordneter Cluster verweist.
Häufig geschieht dies, weil Telefone auf mehreren CUCM-Clustern denselben DHCP-Bereich nutzen und daher über denselben TFTP-Server mit der DHCP-Option 150 verfügen müssen.
Alle IP-Telefone verweisen auf den zentralen TFTP-Cluster, auch wenn sie bei anderen Clustern registriert sind. Dieser zentrale TFTP-Server fragt die Remote-TFTP-Server ab, wenn eine Anforderung für eine nicht auffindbare Datei eingeht.
Aufgrund dieses Vorgangs funktioniert das zentralisierte TFTP nur in einer homogenen ITL-Umgebung.
Auf allen Servern muss CUCM Version 8.x oder höher ausgeführt werden, oder auf allen Servern müssen Versionen vor Version 8.x ausgeführt werden.
Wenn eine Datei ITLFile.tlv vom zentralen TFTP-Server angezeigt wird, vertrauen die Telefone den Dateien vom Remote-TFTP-Server nicht, da die Signaturen nicht übereinstimmen.
Dies geschieht in einer heterogenen Mischung. In einer homogenen Mischung fordert das Telefon ITLSEP<MAC>.tlv an, das aus dem richtigen Remote-Cluster abgerufen wird.
In einer heterogenen Umgebung mit einer Mischung aus Clustern vor Version 8.x und Version 8.x muss "Cluster für Rollback auf Pre 8.0 vorbereiten" auf dem Cluster vor Version 8.x aktiviert werden, wie in Cisco Bug-ID CSCto87262 beschrieben.
Konfigurieren Sie die Parameter für die sichere Telefon-URL mit HTTP anstelle von HTTPS. Dadurch werden die ITL-Funktionen auf dem Telefon deaktiviert.
Sie können SBD nur deaktivieren, wenn SBD und ITL derzeit funktionieren.
SBD kann auf Telefonen mit dem Enterprise-Parameter "Prepare Cluster for Rollback to pre 8.0" (Cluster für Rollback auf vor 8.0 vorbereiten) vorübergehend deaktiviert werden, und indem die "Secured Phone URL Parameters" (Sichere Telefon-URL-Parameter) mit HTTP anstelle von HTTPS konfiguriert werden.
Wenn Sie den Rollback-Parameter festlegen, wird eine signierte ITL-Datei mit leeren Funktionseinträgen erstellt.
Die "leere" ITL-Datei ist noch signiert, daher muss sich der Cluster in einem voll funktionsfähigen Sicherheitsstatus befinden, bevor dieser Parameter aktiviert werden kann.
Nachdem dieser Parameter aktiviert und die neue ITL-Datei mit leeren Einträgen heruntergeladen und verifiziert wurde, akzeptieren die Telefone alle Konfigurationsdateien, unabhängig davon, wer sie signiert hat.
Es wird nicht empfohlen, den Cluster in diesem Zustand zu belassen, da keine der drei zuvor genannten Funktionen (authentifizierte Konfigurationsdateien, verschlüsselte Konfigurationsdateien und HTTPS-URLs) verfügbar sind.
Derzeit gibt es keine Methode, alle ITLs von einem von Cisco remote bereitgestellten Telefon zu löschen. Aus diesem Grund sind die in diesem Dokument beschriebenen Verfahren und Wechselwirkungen so wichtig zu berücksichtigen.
Eine Erweiterung der Cisco Bug-ID CSCto47052 wurde noch nicht behoben. Für diese Funktion ist jedoch noch keine Implementierung erfolgt.
In der Zwischenzeit wurde eine neue Funktion über die Cisco Bug-ID CSCts01319 hinzugefügt, die es dem Cisco Technical Assistance Center (TAC) ermöglicht, auf die zuvor vertrauenswürdige ITL zurückzugreifen, wenn diese auf dem Server weiterhin verfügbar ist.
Dies funktioniert nur in bestimmten Fällen, in denen sich der Cluster in einer Version mit diesem Defektfix befindet und in denen die vorherige ITL in einer Sicherung vorhanden ist, die an einem speziellen Speicherort auf dem Server gespeichert ist.
Sehen Sie sich den Fehler an, um zu sehen, ob Ihre Version die Lösung enthält. Wenden Sie sich an Cisco TAC, um das im Defekt beschriebene potenzielle Wiederherstellungsverfahren durchzuführen.
Wenn das vorherige Verfahren nicht verfügbar ist, müssen die Telefontasten manuell auf das Telefon gedrückt werden, um die ITL-Datei zu löschen. Das ist der Kompromiss zwischen Sicherheit und Verwaltbarkeit. Damit die ITL-Datei wirklich sicher ist, darf sie nicht einfach per Fernzugriff entfernt werden.
Selbst bei per Skript ausgeführten Tastendrücken mit Simple Object Access Protocol (SOAP)-XML-Objekten kann die ITL nicht entfernt werden.
Dies liegt daran, dass der TVS-Zugriff (und damit der Secure Authentication URL-Zugriff zur Validierung eingehender SOAP XML-Push-Objekte) derzeit nicht funktioniert.
Wenn die Authentifizierungs-URL nicht als sicher konfiguriert ist, ist es möglich, ein Skript für die Tastendrücke auszuführen, um eine ITL zu löschen. Dieses Skript ist jedoch nicht bei Cisco verfügbar.
Andere Methoden zur Skripterstellung für Remote-Tastendrücke ohne Verwendung der Authentifizierungs-URL sind möglicherweise von einem Drittanbieter erhältlich, diese Anwendungen werden jedoch nicht von Cisco bereitgestellt.
Die am häufigsten verwendete Methode zum Löschen der ITL ist eine E-Mail-Übertragung an alle Telefonbenutzer, die sie über die Tastenfolge informiert.
Wenn der Einstellungszugriff auf Eingeschränkt oder Deaktiviert eingestellt ist, muss das Telefon auf die Werkseinstellungen zurückgesetzt werden, da die Benutzer keinen Zugriff auf das Einstellungsmenü des Telefons haben.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
2.0 |
14-Jul-2023 |
Rezertifizierung |
1.0 |
27-May-2013 |
Erstveröffentlichung |