Konfigurieren von LSC auf IP-Telefonen mit CUCM

Einleitung

In diesem Dokument wird die Installation eines LSC (Locally Significant Certificate) auf einem Cisco IP-Telefon (Cisco IP Phone) beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco Unified Communications Manager (CUCM) Cluster Security Mode-Optionen
• X.509-Zertifikate
• MICs (Manufacturing Installed Certificates)
• LSCs
• CAPF-Zertifikatvorgänge (Certificate Authority Proxy Function)
• Standardmäßige Sicherheit (Security by Default, SBD)
• ITL-Dateien (Initial Trust List)

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf CUCM-Versionen, die SBD unterstützen, d. h. CUCM 8.0(1) und höher.

Anmerkung: Dies gilt nur für Telefone, die standardmäßig Security By Default (SBD) unterstützen. Beispielsweise unterstützen die Telefone 7940 und 7960 weder SBD noch die Konferenztelefone 7935, 7936 und 7937. Eine Liste der Geräte, die SBD in Ihrer CUCM-Version unterstützen, finden Sie unter Cisco Unified Reporting > System Reports > Unified CM Phone Feature List (Cisco Unified Reporting > Systemberichte > Unified CM Phone-Funktionsliste), und führen Sie einen Bericht zur Funktion aus: Standardmäßig Sicherheit.

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.

Hintergrundinformationen

Der Cisco Authority Proxy Function (CAPF) Service wird nur auf dem Publisher-Knoten ausgeführt. Der Herausgeber fungiert als Zertifizierungsstelle (Certificate Authority, CA) oder Unterzeichner des LSC.

MICs und LSCs

Wenn Sie eine zertifikatbasierte Authentifizierung für 802.1X oder AnyConnect Phone VPN verwenden, ist es wichtig, den Unterschied zwischen MICs und LSCs zu verstehen.

Jedes Cisco Telefon wird mit einem werkseitig vorinstallierten MIC geliefert. Dieses Zertifikat wird von einem der Zertifikate der Cisco Manufacturing CA signiert, entweder vom Cisco Manufacturing CA-, Cisco Manufacturing CA SHA2-, CAP-RTP-001- oder CAP-RTP-002-Zertifikat. Wenn das Telefon dieses Zertifikat präsentiert, weist es nach, dass es sich um ein gültiges Cisco Telefon handelt. Dies stellt jedoch nicht sicher, dass das Telefon zu einem bestimmten Benutzer oder CUCM-Cluster gehört. Es könnte sich dabei um ein unautorisiertes Telefon handeln, das auf dem freien Markt erworben oder von einem anderen Standort aus genutzt wird.

LSCs dagegen werden von einem Administrator absichtlich auf Telefonen installiert und vom CAPF-Zertifikat des CUCM Publisher signiert. Sie sollten 802.1X oder AnyConnect VPN so konfigurieren, dass diese nur vertrauenswürdigen LSCs vertrauen, die von bekannten CAPF-Zertifizierungsstellen ausgestellt wurden. Wenn Sie die Zertifikatsauthentifizierung auf LSCs anstatt auf MICs basieren, erhalten Sie eine viel detailliertere Kontrolle darüber, welchen Telefongeräten vertraut wird.

Konfigurieren

Netzwerktopologie

Die folgenden CUCM-Lab-Server wurden für dieses Dokument verwendet:

• CUCM Publisher und TFTP-Server
• CUCM-Subscriber und TFTP-Server 

Vergewissern Sie sich, dass das CAPF-Zertifikat noch nicht abgelaufen ist und in naher Zukunft ablaufen wird. Navigieren Sie zu Cisco Unified OS Administration > Security > Certificate Management, und suchen Sie dann nach der Zertifikatsliste, in der das Zertifikat genau den CAPF-Wert hat, wie im Bild dargestellt.

Klicken Sie auf Gemeinsamer Name, um die Seite Zertifikatdetails zu öffnen. Prüfen Sie die Gültigkeit von: und an: Datumsangaben im Bereich Zertifikatdateidaten, um zu bestimmen, wann das Zertifikat abläuft, wie im Bild dargestellt.

Wenn das CAPF-Zertifikat abgelaufen ist oder bald ablaufen wird, generieren Sie das Zertifikat neu. Fahren Sie nicht mit dem LSC-Installationsprozess mit einem abgelaufenen oder bald ablaufenden CAPF-Zertifikat fort. Auf diese Weise wird vermieden, dass LSCs nach Ablauf des CAPF-Zertifikats in naher Zukunft neu ausgestellt werden müssen. Weitere Informationen zum Neugenerieren des CAPF-Zertifikats finden Sie im Artikel zum Neugenerieren/Erneuern von CUCM-Zertifikaten.

Ebenso haben Sie in dieser Phase die Möglichkeit, Ihr CAPF-Zertifikat von einer unabhängigen Zertifizierungsstelle signieren zu lassen. Führen Sie die CSR-Dateigenerierung (Certificate Signing Request) und den Import des signierten CAPF-Zertifikats jetzt aus, oder setzen Sie die Konfiguration für einen vorläufigen Test mit einem selbstsignierten LSC fort. Wenn Sie ein von einem Drittanbieter signiertes CAPF-Zertifikat benötigen, ist es in der Regel sinnvoll, diese Funktion zuerst mit einem selbstsignierten CAPF-Zertifikat zu konfigurieren, zu testen und zu überprüfen und dann LSCs erneut bereitzustellen, die von einem von einem von einem Drittanbieter signierten CAPF-Zertifikat signiert wurden. Dies vereinfacht die spätere Fehlerbehebung, wenn die Tests mit dem von einem Drittanbieter signierten CAPF-Zertifikat fehlschlagen.

Warnung: Wenn Sie das CAPF-Zertifikat neu generieren oder ein von einem Drittanbieter signiertes CAPF-Zertifikat importieren, während der CAPF-Dienst aktiviert und gestartet wird, werden die Telefone automatisch vom CUCM zurückgesetzt. Führen Sie diese Schritte in einem Wartungsfenster aus, wenn Telefone zurückgesetzt werden können. Weitere Informationen finden Sie unter Cisco Bug-ID CSCue55353 - Hinzufügen einer Warnung beim Regenerieren des TVS/CCM/CAPF-Zertifikats, das von Telefonen zurückgesetzt wird.

Anmerkung: Wenn Ihre CUCM-Version SBD unterstützt, gilt dieses LSC-Installationsverfahren unabhängig davon, ob Ihr CUCM-Cluster auf den gemischten Modus eingestellt ist oder nicht. SBD ist Teil von CUCM Version 8.0(1) und höher. In diesen Versionen von CUCM enthalten die ITL-Dateien das Zertifikat für den CAPF-Dienst auf dem CUCM Publisher. Dadurch können sich Telefone mit dem CAPF-Dienst verbinden, um Zertifikatvorgänge wie Installation/Upgrade und Fehlerbehebung zu unterstützen.

In den früheren Versionen von CUCM war es erforderlich, den Cluster für den gemischten Modus zu konfigurieren, um Zertifikatvorgänge zu unterstützen. Da dies nicht mehr erforderlich ist, werden die Hindernisse für die Verwendung von LSCs als Telefon-Identitätszertifikate für die 802.1X-Authentifizierung oder die AnyConnect VPN-Client-Authentifizierung beseitigt.

Führen Sie den Befehl show itl auf allen TFTP-Servern im CUCM-Cluster aus. Beachten Sie, dass die ITL-Datei ein CAPF-Zertifikat enthält.

Dies ist beispielsweise ein Auszug aus der show itl-Ausgabe des CUCM-Subscribers ao115sub.

Anmerkung: In dieser Datei befindet sich ein ITL-Eintrag mit der FUNKTION CAPF.

Anmerkung: Wenn Ihre ITL-Datei keinen CAPF-Eintrag enthält, melden Sie sich bei Ihrem CUCM-Publisher an, und bestätigen Sie, dass der CAPF-Dienst aktiviert ist. Um dies zu bestätigen, navigieren Sie zu Cisco Unified Serviceability > Tools > Service Activation > CUCM Publisher > Security, und aktivieren Sie dann den Cisco Certificate Authority Proxy Function Service. Wenn der Service deaktiviert und gerade aktiviert wurde, navigieren Sie zu Cisco Unified Serviceability > Tools > Control Center - Feature Services > Server > CM Services, und starten Sie den Cisco TFTP-Service auf allen TFTP-Servern im CUCM-Cluster neu, um die ITL-Datei neu zu generieren. Achten Sie außerdem darauf, dass Sie die Cisco Bug-ID CSCuj78330 nicht erreichen.

Hinweis: Führen Sie nach Abschluss des Vorgangs den Befehl show itl auf allen TFTP-Servern im CUCM-Cluster aus, um zu überprüfen, ob das aktuelle CAPF-Zertifikat des CUCM Publisher jetzt in der Datei enthalten ist.

 ITL Record #:1
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 727
2 DNSNAME 2
3 SUBJECTNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 64:F2:FE:61:3B:79:C5:D3:62:E2:6D:AB:4A:8B:76:1B
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 C3 E6 97 D0 8A E1 0B F2 31 EC ED 20 EC C5 BC 0F 83 BC BC 5E
12 HASH ALGORITHM 1 null

 ITL Record #:2
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 6B:99:31:15:D1:55:5E:75:9C:42:8A:CE:F2:7E:EA:E8
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 05 9A DE 20 14 55 23 2D 08 20 31 4E B5 9C E9 FE BD 2D 55 87
12 HASH ALGORITHM 1 null

 ITL Record #:3
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1680
2 DNSNAME 2
3 SUBJECTNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 51:BB:2F:1C:EE:80:02:16:62:69:51:9A:14:F6:03:7E
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 963 DF 98 C1 DB E0 61 02 1C 10 18 D8 BA F7 1B 2C AB 4C F8 C9 D5 (SHA1 Hash HEX)
This etoken was not used to sign the ITL file.

 ITL Record #:4
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 65:E5:10:72:E7:F8:77:DA:F1:34:D5:E3:5A:E0:17:41
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 00 44 54 42 B4 8B 26 24 F3 64 3E 57 8D 0E 5F B0 8B 79 3B BF
12 HASH ALGORITHM 1 null

 ITL Record #:5
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

 ITL Record #:6
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)

 ITL Record #:7
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1031
2 DNSNAME 9 ao115sub
3 SUBJECTNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 53:CC:1D:87:BA:6A:28:BD:DA:22:B2:49:56:8B:51:6C
7 PUBLICKEY 97
8 SIGNATURE 103
9 CERTIFICATE 651 E0 CF 8A B3 4F 79 CE 93 03 72 C3 7A 3F CF AE C3 3E DE 64 C5 (SHA1 Hash HEX)

The ITL file was verified successfully.

Nachdem der CAPF-Eintrag als Eintrag im ITL bestätigt wurde, können Sie einen Zertifikatvorgang auf einem Telefon abschließen. In diesem Beispiel wird ein 2048-Bit-RSA-Zertifikat mithilfe der Null-String-Authentifizierung installiert.

Überprüfen Sie am Telefon, ob noch kein LSC installiert ist, wie im Bild gezeigt. Navigieren Sie z. B. auf einem Telefon der Serie 79XX zu Einstellungen > 4 - Sicherheitskonfiguration > 4 - LSC.

Öffnen Sie die Seite für die Telefonkonfiguration Ihres Telefons. Navigieren Sie zu Cisco Unified CM Administration > Device > Phone (Gerät > Telefon).

Geben Sie im Bereich "CAPF Information" (CAPF-Informationen) der Konfiguration des Telefons die folgenden Details ein, wie im Bild gezeigt:

• Wählen Sie als Zertifikatvorgang Install/Upgrade (Installieren/Aktualisieren).
• Wählen Sie für den Authentifizierungsmodus By Null String (Nach NULL-Zeichenfolge).
• Lassen Sie für dieses Beispiel die Schlüsselreihenfolge, die RSA-Schlüsselgröße (Bits) und die EC-Schlüsselgröße (Bits) auf die Systemstandardwerte festgelegt.
• Geben Sie für "Arbeitsvorgang abgeschlossen bis" ein Datum und eine Uhrzeit ein, die mindestens eine Stunde in der Zukunft liegen.

Speichern Sie die Konfigurationsänderungen, und wenden Sie die Konfiguration an.

Der LSC-Status auf dem Telefon ändert sich in Ausstehend, wie im Bild gezeigt.

Das Telefon generiert Schlüssel, wie im Bild dargestellt.

Das Telefon wird zurückgesetzt, und wenn das Zurücksetzen abgeschlossen ist, ändert sich der LSC-Status des Telefons in Installed (Installiert), wie im Bild gezeigt.

Dies wird auch unter "Statusmeldungen" im Telefon angezeigt, wie im Bild gezeigt.

Überprüfung

Verwenden Sie diesen Abschnitt, um zu überprüfen, ob Ihre Konfiguration ordnungsgemäß funktioniert.

Informationen zur Überprüfung der Installation von LSC-Zertifikaten auf mehreren Telefonen finden Sie im Abschnitt Generate CAPF Report (CAPF-Bericht generieren) des Sicherheitsleitfadens für Cisco Unified Communications Manager, Version 11.0(1). Alternativ können Sie die gleichen Daten auch in der CUCM-Administration-Webschnittstelle anzeigen, indem Sie die Prozedur "Telefone nach LSC-Status suchen" oder "Authentifizierungszeichenfolge" verwenden.

Informationen zum Abrufen von Kopien der in Telefonen installierten LSC-Zertifikate finden Sie im Artikel Abrufen von Zertifikaten von Cisco IP-Telefonen.

Große LSC-Installation

In diesem Abschnitt können Sie LCS in großen Mengen auf Telefone desselben Modells hochladen.

1. Navigieren Sie zu Bulk Administration > Phones > Update Phones > Query.
2. Suchen Sie nach Telefonen, deren Gerätetyp <vierstellige Modellnummer eingeben> enthält, und wählen Sie Suchen und dann Weiter aus.
3. Scrollen Sie zum Abschnitt CAPF-Informationen (Certification Authority Proxy Function).
4. Wählen Sie im Dropdown-Abschnitt die Option Install/Upgrade (Installieren/Aktualisieren) aus.

Wenn Sie die Massenverwaltung verwenden und den Authentifizierungsmodus auswählen, muss der Authentifizierungsmodus mit dem Betrieb des Telefonsicherheitsprofils übereinstimmen.  Wenn eine Diskrepanz vorliegt, z. B. "Nach NULL-Zeichenfolge in Masse" und "Nach vorhandenem Zertifikat (Vorrang für LSC)" im Telefonsicherheitsprofil, kann der Vorgang nicht abgeschlossen werden.

Überprüfen Sie das Telefon-Sicherheitsprofil und den Authentifizierungsmodus, um sicherzustellen, dass Sie den richtigen Modus verwenden.

LSC nach LSC-Rangfolge

Um eine Massenkonfiguration einzurichten, wählen Sie im Dropdown-Menü den Authentifizierungsmodus aus, der mit dem Telefonsicherheitsprofil übereinstimmt.

Massenauswahl

Wenn Sie den Authentifizierungsmodus des Telefonsicherheitsprofils ändern, müssen Sie speichern und dann die Konfiguration anwenden.  Dies kann dazu führen, dass diese Geräte, die das spezifische Telefon-Sicherheitsprofil verwenden, neu gestartet werden.

Authentifizierungsauswahl

Fehlerbehebung

In diesem Abschnitt erhalten Sie Informationen zur Behebung von Fehlern in Ihrer Konfiguration.

Kein gültiger CAPF-Server

Das LSC kann nicht installiert werden. Die Statusmeldung des Telefons lautet "No valid CAPF server" (Kein gültiger CAPF-Server). Dies weist darauf hin, dass in der ITL-Datei kein CAPF-Eintrag vorhanden ist. Überprüfen Sie, ob der CAPF-Dienst aktiviert wurde, und starten Sie dann den TFTP-Dienst neu. Überprüfen Sie nach dem Neustart, ob die ITL-Datei ein CAPF-Zertifikat enthält, setzen Sie das Telefon zurück, um die neueste ITL-Datei abzurufen, und wiederholen Sie dann den Zertifikatvorgang. Wenn der CAPF-Servereintrag im Menü mit den Sicherheitseinstellungen des Telefons als Hostname oder vollständig qualifizierter Domänenname angezeigt wird, stellen Sie sicher, dass das Telefon den Eintrag in eine IP-Adresse auflösen kann.

LSC: Verbindung fehlgeschlagen

Das LSC kann nicht installiert werden. Die Statusmeldungen des Telefons zeigen Folgendes an: "LSC: Verbindung fehlgeschlagen". Dies kann auf eine der folgenden Bedingungen hinweisen:

• Wenn das CAPF-Zertifikat in der ITL-Datei nicht mit dem aktuellen Zertifikat übereinstimmt, wird der CAPF-Dienst verwendet.
• Der CAPF-Dienst wird beendet oder deaktiviert.
• Das Telefon kann den CAPF-Dienst nicht über das Netzwerk erreichen.

Vergewissern Sie sich, dass der CAPF-Dienst aktiviert ist, starten Sie den CAPF-Dienst neu, starten Sie die TFTP-Dienste neu, und setzen Sie das Telefon zurück, um die neueste ITL-Datei abzurufen. Wiederholen Sie anschließend den Vorgang für das Zertifikat. Wenn das Problem weiterhin besteht, erfassen Sie die Pakete vom Telefon und vom CUCM Publisher, und analysieren Sie, um festzustellen, ob auf Port 3804, dem standardmäßigen CAPF-Service-Port, eine bidirektionale Kommunikation besteht. Andernfalls kann es zu einem Netzwerkproblem kommen.

LSC: Fehler

Das LSC kann nicht installiert werden. Die Statusmeldungen des Telefons zeigen Folgendes an: "LSC: Fehlgeschlagen" Die Webseite "Phone Configuration" (Telefonkonfiguration) zeigt den Status "Certificate Operation Status: Upgrade fehlgeschlagen: Vom Benutzer initiierte Anfrage verspätet/abgelaufen". Dies zeigt an, dass der Vorgang "Abgeschlossen nach" abgelaufen ist oder in der Vergangenheit liegt. Geben Sie ein Datum und eine Uhrzeit ein, die mindestens eine Stunde in die Zukunft liegen, und wiederholen Sie dann den Zertifikatvorgang.

LSC: Vorgang ausstehend

Das LSC kann nicht installiert werden. Die Statusmeldungen des Telefons zeigen Folgendes an: "LSC: Verbindung fehlgeschlagen". Auf der Seite für die Telefonkonfiguration wird der Status "Certificate Operation Status: Vorgang ausstehend". Der Status des Zertifikatvorgangs kann aus verschiedenen Gründen angezeigt werden: Vorgang Ausstehender Status. Dazu gehören:

• ITL auf dem Telefon unterscheidet sich von dem derzeit auf den konfigurierten TFTP-Servern verwendeten.
• Probleme mit beschädigten ITLs. In diesem Fall verlieren Geräte ihren vertrauenswürdigen Status, und der Befehl utils itl reset localkey muss vom CUCM Publisher ausgeführt werden, damit die Telefone das ITLRecovery-Zertifikat verwenden. Wenn sich der Cluster im gemischten Modus befindet, müssen Sie den Befehl utils ctl reset localkey verwenden. Als Nächstes sehen Sie ein Beispiel für die Anzeige einer beschädigten ITL über die CLI von CUCM. Wenn beim Versuch, die ITL anzuzeigen, ein Fehler auftritt und versucht wird, den Befehl utils itl reset localkey auszuführen, aber der zweite Fehler angezeigt wird, kann dies ein Fehler mit der Cisco Bug-ID CSCus33755 sein. Bestätigen Sie, ob die Version von CUCM betroffen ist.

• Das Telefon kann die neue LSC aufgrund eines TVS-Fehlers nicht authentifizieren.
• Das Telefon verwendet das MIC-Zertifikat, aber im Abschnitt CAPF-Informationen (Certificate Authority Proxy Function) auf der Seite für die Telefonkonfiguration wurde der Authentifizierungsmodus durch vorhandenes Zertifikat festgelegt (Precedence zu LSC).
• Das Telefon kann den FQDN des CUCM nicht auflösen.

Im letzten Szenario wird eine Laborumgebung eingerichtet, um zu simulieren, was in den Protokollen angezeigt wird, wenn ein Telefon den FQDN von CUCM nicht auflösen kann. Derzeit umfasst die Übung folgende Server:

• CUCM Publisher und Subscriber mit Version 11.5.1.15038-2
• Windows 2016 Server-Setup als DNS-Server

Für den Test ist kein DNS-Eintrag für den PUB11 CUCM-Server konfiguriert.

Versucht, ein LSC an eines der Telefone (8845) in der Übung zu verschieben. Überprüfen Sie, ob der Status des Zertifikatvorgangs weiterhin angezeigt wird: Vorgang ausstehend.

Überprüfen Sie in den Telefonkonsolenprotokollen, ob das Telefon versucht, den lokalen Cache (127.0.0.1) abzufragen, bevor die Abfrage an die konfigurierte DNS-Serveradresse weitergeleitet wird.

0475 INF Mar 12 15:07:53.686410 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0476 INF Mar 12 15:07:53.686450 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0477 INF Mar 12 15:07:53.694909 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0478 INF Mar 12 15:07:53.695263 dnsmasq[12864]: reply PUB11.brianw2.lab is NXDOMAIN-IPv4
0479 INF Mar 12 15:07:53.695833 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0480 INF Mar 12 15:07:53.695865 dnsmasq[12864]: cached PUB11.brianw2.lab is NXDOMAIN-IPv4
0481 WRN Mar 12 15:07:53.697091 (12905:13036) JAVA-configmgr MQThread|NetUtil.traceIPv4DNSErrors:? - DNS unknown IPv4 host PUB11.brianw2.lab

++ However, we see that the phone is not able to resolve the FQDN of the CUCM Publisher. This is because we need to configure the DNS entry for PUB11 on our DNS server.

0482 ERR Mar 12 15:07:53.697267 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Failed to resolve Tvs Ipv4 Address with hostname PUB11.brianw2.lab

++ Afterwards, we see the CAPF operation fail. This is expected because we do not have a DNS mapping for PUB11. 

0632 NOT Mar 12 15:07:55.760715 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty:? - CertificateProperty.setCertificate() authMode=CAPF_AUTH_MODE_NULL_STR authorizationString=null theReason=CAPF_REASON_AUTO
0633 NOT Mar 12 15:07:55.761649 (322:17812) SECUREAPP-RCAPF_START_MODE: Start CAPF - mode:[1]([NULL_STR]), reason:[1]([AUTO]) no auth-str
0634 NOT Mar 12 15:07:55.761749 (322:17812) SECUREAPP-CAPF_CLNT_INIT:CAPF clnt initialized
0635 NOT Mar 12 15:07:55.761808 (322:17812) SECUREAPP-CAPFClnt: SetDelayTimer - set with value <0>
0636 ERR Mar 12 15:07:55.761903 (322:17812) SECUREAPP-Sec create BIO - invalid parameter.
0637 ERR Mar 12 15:07:55.761984 (322:17812) SECUREAPP-SEC_CAPF_BIO_F: CAPF create bio failed
0638 ERR Mar 12 15:07:55.762040 (322:17812) SECUREAPP-SEC_CAPF_OP_F: CAPF operation failed, ret -7
0639 CRT Mar 12 15:07:55.863826 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty$1:? - LSC: Connection failed

++ What we would expect to see is something similar to the following where DNS replies with the IP address that is associated with the FQDN of CUCM. After configuring a AAAA record in DNS for PUB11, we now see the below result in the console logs.

4288 INF Mar 12 16:34:06.162666 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
4289 INF Mar 12 16:34:06.162826 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
4290 INF Mar 12 16:34:06.164908 dnsmasq[12864]: reply PUB11.brianw2.lab is X.X.X.X
4291 NOT Mar 12 16:34:06.165024 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Resolve Tvs Ipv4 Address to X.X.X.X from hostname PUB11.brianw2.lab

Sehen Sie in den Telefonstatusmeldungen, dass das Telefon PUB11.brianw2.lab nicht auflösen kann. Anschließend siehe "LSC: Verbindung" fehlgeschlagen.

Zu berücksichtigende Mängel:

Cisco Bug-ID CSCub6243 - LSC-Installation schlägt gelegentlich fehl und friert danach den CAPF-Server ein.

Zu berücksichtigender Erweiterungsfehler:

Cisco Bug-ID CSCuz18034 - Meldung erforderlich, wenn Endgeräte mit LSC-Installation und Ablaufstatus angezeigt werden.

Zugehörige Informationen

Diese Dokumente enthalten weitere Informationen zur Verwendung von LSCs im Kontext für die AnyConnect VPN-Client-Authentifizierung und die 802.1X-Authentifizierung.

• AnyConnect VPN-Telefon - Fehlerbehebung für IP-Telefone, ASA und CUCM
• Identitätsbasierte Netzwerkservices: IP-Telefonie in IEEE 802.1X-fähigen Netzwerken - Bereitstellungs- und Konfigurationsleitfaden

Es gibt auch einen erweiterten LSC-Konfigurationstyp, bei dem die LSC-Zertifikate direkt von einer Zertifizierungsstelle eines Drittanbieters signiert werden, nicht vom CAPF-Zertifikat.

Weitere Informationen finden Sie unter Konfigurationsbeispiel zum Generieren und Importieren von LSCs mit CA-Signatur von CUCM-Drittanbietern.

• Technischer Support und Dokumentation für Cisco Systeme