LSC configureren op IP-telefoon met CUCM

Inleiding

In dit document wordt beschreven hoe u een lokaal significant certificaat (LSC) installeert op een Cisco Internet Protocol Phone (Cisco IP Phone).

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Cisco Unified Communications Manager (CUCM) Cluster Security Mode-opties
• X.509-certificaten
• Geïnstalleerde productiecertificaten (MIC's)
• LSC's
• Certificaatautoriteit Proxyfunctie (CAPF) certificaatbewerkingen
• Standaard beveiliging (SBD)
• Initial Trust List (ITL)-bestanden

Gebruikte componenten

De informatie in dit document is gebaseerd op CUCM-versies die SBD ondersteunen, namelijk CUCM 8.0(1) en hoger.

Opmerking: het heeft alleen betrekking op telefoons die Security By Default (SBD) ondersteunen. Bijvoorbeeld, de 7940 en 7960 telefoons ondersteunen geen SBD, noch de 7935, 7936 en 7937 conferentie telefoons. Voor een lijst met apparaten die SBD ondersteunen in uw versie van CUCM, gaat u naar Cisco Unified Reporting > Systeemrapporten > Unified CM Phone Feature List en voert u een rapport uit over Feature: Security By Default.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

De Cisco Authority Proxy Function (CAPF)-service wordt alleen uitgevoerd op de node van de uitgever. De uitgever treedt op als de Certificate Authority (CA) of ondertekenaar van de LSC.

MIC's versus LSC's

Als u verificatie op basis van certificaten gebruikt voor 802.1X of AnyConnect Phone VPN, is het belangrijk om het verschil tussen MIC's en LSC's te begrijpen.

Elke Cisco-telefoon wordt geleverd met een vooraf geïnstalleerde MIC in de fabriek. Dit certificaat is ondertekend door een van de Cisco Manufacturing CA-certificaten, hetzij door het Cisco Manufacturing CA, Cisco Manufacturing CA SHA2, CAP-RTP-001 of CAP-RTP-002-certificaat. Wanneer de telefoon dit certificaat presenteert, bewijst dit dat het een geldige Cisco-telefoon is, maar dit bevestigt niet dat de telefoon tot een specifieke gebruiker of CUCM-cluster behoort. Het zou mogelijk een malafide telefoon kunnen zijn die op de open markt is gekocht of van een andere site is overgedragen.

LSC's daarentegen worden opzettelijk geïnstalleerd op telefoons door een beheerder en zijn ondertekend door het CAPF-certificaat van de CUCM-uitgever. U configureert 802.1X of AnyConnect VPN om alleen LSC's te vertrouwen die zijn uitgegeven door bekende CAPF-certificeringsinstanties. Het baseren van certificaatverificatie op LSC's in plaats van MIC's biedt u een veel gedetailleerdere controle over welke telefoonapparaten worden vertrouwd.

Configureren

Netwerktopologie

Deze CUCM-labservers werden gebruikt voor dit document:

• CUCM Publisher en TFTP-server
• CUCM-abonnee en TFTP-server 

Controleer of het CAPF-certificaat niet is verlopen en niet binnenkort verloopt. Navigeer naar Cisco Unified OS Administration > Security > Certificate Management, en zoek vervolgens Certificaatlijst waar Certificaat precies CAPF is zoals weergegeven in de afbeelding.

Klik op Algemene naam om de pagina Certificaatdetails te openen. Controleer de datums Geldigheid van: en tot: in het deelvenster Gegevens van certificaatbestand om te bepalen wanneer het certificaat verloopt, zoals in de afbeelding wordt weergegeven.

Als het CAPF-certificaat is verlopen of binnenkort verloopt, moet u dat certificaat opnieuw genereren. Ga niet verder met het LSC-installatieproces met een verlopen of binnenkort verlopen CAPF-certificaat. Dit voorkomt de noodzaak om LSC's in de nabije toekomst opnieuw uit te geven vanwege de vervaldatum van het CAPF-certificaat. Voor informatie over het regenereren van het CAPF-certificaat, raadpleegt u het artikel CUCM Certificate Regeneration/Renewal Process.

Evenzo, als u uw CAPF-certificaat moet laten ondertekenen door een certificeringsinstantie van een derde partij, moet u in dit stadium een keuze maken. Voltooi nu het genereren en importeren van het ondertekende certificaat voor het aanvragen van een certificaatondertekening (Certificate Signing Request, CSR) of ga door met de configuratie met een zelf ondertekend LSC voor een voorlopige test. Als u een door een derde partij ondertekend CAPF-certificaat nodig hebt, is het over het algemeen verstandig om deze functie eerst te configureren met een zelf ondertekend CAPF-certificaat, te testen en te verifiëren en vervolgens LSC's opnieuw in te zetten die zijn ondertekend door een door een derde partij ondertekend CAPF-certificaat. Dit vereenvoudigt het later oplossen van problemen als tests met het door derden ondertekende CAPF-certificaat mislukken.

Waarschuwing: Als u het CAPF-certificaat opnieuw genereert of een door derden ondertekend CAPF-certificaat importeert terwijl de CAPF-service wordt geactiveerd en gestart, worden telefoons automatisch gereset door CUCM. Voltooi deze procedures in een onderhoudsvenster wanneer het acceptabel is om telefoons opnieuw in te stellen. Zie Cisco bug ID CSCue55353 - Waarschuwing toevoegen bij het regenereren van TVS/CCM/CAPF-certificaat dat telefoons reset

Opmerking: als uw CUCM-versie SBD ondersteunt, is deze LSC-installatieprocedure van toepassing, ongeacht of uw CUCM-cluster is ingesteld op de gemengde modus of niet. SBD is een onderdeel van CUCM versie 8.0(1) en hoger. In deze versies van CUCM bevatten de ITL-bestanden het certificaat voor de CAPF-service op de CUCM Publisher. Hierdoor kunnen telefoons verbinding maken met de CAPF-service om certificaatbewerkingen zoals installeren/upgraden en probleemoplossing te ondersteunen.

In de vorige versies van CUCM moest het cluster worden geconfigureerd voor de gemengde modus om certificaatbewerkingen te ondersteunen. Aangezien dit niet langer nodig is, worden hiermee de belemmeringen voor het gebruik van LSC's als identiteitscertificaten voor 802.1X-verificatie of voor AnyConnect VPN-clientverificatie verminderd.

Voer de opdracht show itl uit op alle TFTP-servers in het CUCM-cluster. Merk op dat het ITL-bestand wel een CAPF-certificaat bevat.

Hier is bijvoorbeeld een fragment van de show itl-uitvoer van het lab CUCM Subscriber ao115sub.

Opmerking: er is een ITL Record-vermelding in dit bestand met een FUNCTIE van CAPF.

Opmerking: Als uw ITL-bestand geen CAPF-vermelding heeft, meldt u zich aan bij uw CUCM-uitgever en bevestigt u dat de CAPF-service is geactiveerd. Om dit te bevestigen, gaat u naar Cisco Unified Serviceability > Tools > Service Activation > CUCM Publisher > Security en activeert u vervolgens de Cisco Certificate Authority Proxy Function Service. Als de service is gedeactiveerd en u deze zojuist hebt geactiveerd, navigeert u naar Cisco Unified Serviceability > Tools > Control Center – Feature Services > Server > CM Services, start u de Cisco TFTP-service opnieuw op alle TFTP-servers in het CUCM-cluster om het ITL-bestand opnieuw te genereren. Zorg er ook voor dat u geen Cisco bug ID CSCuj78330 raakt.

Opmerking: Als u klaar bent, voert u de opdracht show itl uit op alle TFTP-servers in het CUCM-cluster om te controleren of het huidige CUCM Publisher CAPF-certificaat nu in het bestand is opgenomen.

 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.

Met de CAPF-vermelding bevestigd als een vermelding in de ITL, kunt u een certificaatbewerking op een telefoon voltooien. In dit voorbeeld wordt een 2048-bits RSA-certificaat geïnstalleerd met behulp van Null String-verificatie.

Controleer aan de telefoon of er nog geen LSC is geïnstalleerd, zoals in de afbeelding wordt weergegeven. Navigeer bijvoorbeeld op een telefoon uit de 79XX-reeks naar Instellingen > 4 - Beveiligingsconfiguratie > 4 - LSC.

Open de telefoonconfiguratiepagina voor uw telefoon. Navigeer naar Cisco Unified CM Administration > Apparaat > Telefoon.

Voer deze gegevens in het gedeelte CAPF-informatie van de configuratie van de telefoon in, zoals weergegeven in de afbeelding:

• Kies Installeren/upgraden voor Certificaatbewerking.
• Kies voor de verificatiemodus Door null-tekenreeks.
• Laat in dit voorbeeld de sleutelvolgorde, RSA-sleutelgrootte (bits) en EC-sleutelgrootte (bits) op de standaardwaarden van het systeem staan.
• Voer voor Bewerking voltooid door een datum en tijd in die ten minste één uur in de toekomst liggen.

Sla uw configuratiewijzigingen op en pas Config toe.

De LSC-status op de telefoon verandert in In behandeling zoals weergegeven in de afbeelding.

De telefoon genereert toetsen zoals weergegeven in de afbeelding.

De telefoon wordt opnieuw ingesteld en wanneer de reset is voltooid, verandert de LSC-status van de telefoon in Geïnstalleerd, zoals weergegeven in de afbeelding.

Dit is ook zichtbaar onder Statusberichten in de telefoon zoals weergegeven in de afbeelding.

Verifiëren

Gebruik deze sectie om te controleren of uw configuratie goed werkt.

Als u de installatie van het LSC-certificaat op meerdere telefoons wilt controleren, raadpleegt u het gedeelte Rapport van CAPF genereren van de Beveiligingsgids voor Cisco Unified Communications Manager, versie 11.0(1). U kunt ook dezelfde gegevens bekijken in de webinterface CUCM-beheer met behulp van de procedure Telefoons zoeken op LSC-status of Authenticatie-tekenreeks.

Raadpleeg het artikel Certificaten ophalen van Cisco IP-telefoons voor het verkrijgen van kopieën van de LSC-certificaten die in telefoons zijn geïnstalleerd.

LSC-installatie in bulk

Gebruik dit gedeelte om LCS in bulk naar dezelfde modeltelefoons te uploaden.

1. Navigeer naar Bulkbeheer > Telefoons > Telefoons bijwerken > Query.
2. Zoek telefoons met apparaattype <Voer het modelnummer van vier cijfers in> selecteer Zoeken en vervolgens Volgende.
3. Blader naar de sectie Informatie over de proxy-functie van de certificeringsinstantie.
4. Kies in de vervolgkeuzelijst Installeren/upgraden.

Wanneer u Bulkbeheer gebruikt en de verificatiemodus selecteert, moet de verificatiemodus overeenkomen met de werking van het beveiligingsprofiel van de telefoon.  Als er een mismatch is, bijvoorbeeld door Null-tekenreeks in bulk en door bestaand certificaat (voorrang op LSC) in het beveiligingsprofiel van de telefoon, kan de bewerking niet worden voltooid.

Controleer het beveiligingsprofiel van de telefoon en de verificatiemodus om ervoor te zorgen dat u de juiste modus gebruikt.

LSC door LSC Precedence

Als u bulkconfiguratie wilt instellen, selecteert u in de vervolgkeuzelijst de verificatiemodus die overeenkomt met het beveiligingsprofiel voor de telefoon.

Bulkselectie

Als u de verificatiemodus voor het beveiligingsprofiel van de telefoon wijzigt, moet u Opslaan en vervolgens de configuratie toepassen.  Dit kan ertoe leiden dat apparaten die het specifieke Telefoonbeveiligingsprofiel gebruiken, opnieuw worden opgestart.

Authenticatieselectie

Problemen oplossen

Deze sectie bevat informatie die u kunt gebruiken om problemen met de configuratie te troubleshooten.

Geen geldige CAPF-server

De LSC kan niet worden geïnstalleerd. De statusberichten van de telefoon tonen "Geen geldige CAPF-server". Dit geeft aan dat er geen CAPF-vermelding in het ITL-bestand is. Controleer of de CAPF-service is geactiveerd en start vervolgens de TFTP-service opnieuw op. Controleer of het ITL-bestand na het opnieuw opstarten een CAPF-certificaat bevat, stel de telefoon opnieuw in om het nieuwste ITL-bestand op te halen en probeer vervolgens de certificaatbewerking opnieuw. Als de vermelding CAPF-server in het menu Beveiligingsinstellingen van de telefoon wordt weergegeven als hostnaam of volledig gekwalificeerde domeinnaam, bevestigt u dat de telefoon de vermelding naar een IP-adres kan oplossen.

LSC: verbinding mislukt

De LSC kan niet worden geïnstalleerd. De statusberichten van de telefoon tonen "LSC: verbinding mislukt". Dit kan wijzen op een van deze voorwaarden:

• Als het CAPF-certificaat in het ITL-bestand niet overeenkomt met het huidige certificaat, wordt de CAPF-service gebruikt.
• De CAPF-service wordt gestopt of gedeactiveerd.
• De telefoon kan de CAPF-service niet via het netwerk bereiken.

Controleer of de CAPF-service is geactiveerd, start de CAPF-service opnieuw op, start de TFTP-services opnieuw op waar deze zijn gestart, stel de telefoon opnieuw in om het nieuwste ITL-bestand op te halen en probeer vervolgens uw certificaatbewerking opnieuw. Als het probleem aanhoudt, neemt u een pakketopname van de telefoon en de CUCM-uitgever en analyseert u om te zien of er bidirectionele communicatie is op poort 3804, de standaard CAPF-servicepoort. Zo niet, dan kan er een netwerkprobleem zijn.

LSC: mislukt

De LSC kan niet worden geïnstalleerd. De statusberichten van de telefoon tonen "LSC: Failed". De webpagina Telefoonconfiguratie toont "Status certificaatbewerking: upgrade mislukt: door gebruiker geïnitieerd verzoek/late time-out". Dit geeft aan dat de bewerking op tijd en datum is voltooid of in het verleden is verlopen. Voer een datum en tijd in die ten minste een uur in de toekomst liggen en probeer vervolgens de certificaatbewerking opnieuw.

LSC: operatie in behandeling

De LSC kan niet worden geïnstalleerd. De statusberichten van de telefoon tonen "LSC: verbinding mislukt". Op de pagina Configuratie telefoon ziet u "Status certificaatbewerking: bewerking in behandeling". Er zijn verschillende redenen waarom u de status Certificaatbewerking kunt zien: Bewerking in behandeling. Enkele daarvan zijn:

• ITL op de telefoon is anders dan die momenteel wordt gebruikt op de geconfigureerde TFTP-servers.
• Problemen met corrupte ITL's. Wanneer dit gebeurt, verliezen apparaten hun vertrouwde status en het commando utils itl reset localkey moet worden uitgevoerd vanuit de CUCM Publisher om de telefoons te dwingen om nu het ITLRrecovery-certificaat te gebruiken. Als het cluster zich in de gemengde modus bevindt, moet u de opdracht ctl reset localkey gebruiken. Vervolgens ziet u een voorbeeld van wat u kunt zien wanneer u probeert een corrupte ITL te bekijken vanuit de CLI van CUCM. Als er een fout optreedt wanneer u probeert de ITL te bekijken en probeert de opdracht itl reset localkey uit te voeren, maar u ziet de tweede fout, kan dit een fout zijn Cisco bug ID CSCus33755. Bevestig of de versie van de CUCM is gewijzigd.

• Telefoon kan de nieuwe LSC niet verifiëren vanwege een tv-fout.
• Telefoon gebruikt het MIC-certificaat, maar de sectie Certificaatautoriteit proxy-functie (CAPF) Informatie op de configuratiepagina van de telefoon heeft de verificatiemodus ingesteld op Bestaand certificaat (Voorrang voor LSC).
• Telefoon kan de FQDN van CUCM niet oplossen.

Voor het laatste scenario wordt een laboratoriumomgeving ingesteld om te simuleren wat u in de logs zou zien als een telefoon de FQDN van CUCM niet kon oplossen. Momenteel is het lab opgezet met deze servers:

• CUCM Uitgever en Abonnee met versie 11.5.1.15038-2
• Windows 2016 Server instellen als mijn DNS-server

Voor de test is er geen DNS-vermelding voor de PUB11 CUCM-server geconfigureerd.

Poging om een LSC naar een van de telefoons (8845) in het lab te duwen. Zie dat het nog steeds Certificate Operation Status: Operation Pending (Bewerking in behandeling) toont.

In de logboeken van de telefoonconsole ziet u dat de telefoon probeert de lokale cache (127.0.0.1) op te vragen voordat de query wordt doorgestuurd naar het geconfigureerde DNS-serveradres.

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

Zie in de telefoonstatusberichten dat de telefoon PUB11.brianw2.lab niet kan oplossen. Zie daarna het bericht "LSC: Connection" mislukt.

Gebreken om te overwegen:

Cisco bug ID CSCub62243 - LSC installatie mislukt met tussenpozen en daarna bevriest de CAPF Server.

Verbeteringsfout om te overwegen:

Cisco bug ID CSCuz18034 - Vereiste rapportage voor LSC geïnstalleerde eindpunten en vervalstatus.

Gerelateerde informatie

Deze documenten bieden meer informatie over het gebruik van LSC's in het kader van AnyConnect VPN-clientverificatie en 802.1X-verificatie.

• AnyConnect VPN Phone - IP-telefoons, ASA en CUCM Problemen oplossen
• Op identiteit gebaseerde netwerkservices: handleiding voor implementatie en configuratie van IP-telefonie in IEEE 802.1X-netwerken

Er is ook een geavanceerd type LSC-configuratie, waarbij de LSC-certificaten rechtstreeks worden ondertekend door een externe certificeringsinstantie, niet door het CAPF-certificaat.

Zie voor meer informatie: Voorbeeld van de CA-ondertekende LSC's van derde partijen voor genereren en importeren van CUCM

• Technische ondersteuning en documentatie – Cisco Systems