CUCM을 사용하여 IP Phone에 LSC 구성

소개

이 문서에서는 Cisco IP Phone(Cisco Internet Protocol Phone)에 LSC(Locally Significant Certificate)를 설치하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• CUCM(Cisco Unified Communications Manager) 클러스터 보안 모드 옵션
• X.509 인증서
• MIC(Manufacturing Installed Certificates)
• LSC
• CAPF(Certificate Authority Proxy Function) 인증서 작업
• 기본 보안(SBD)
• ITL(Initial Trust List) 파일

사용되는 구성 요소

이 문서의 정보는 SBD를 지원하는 CUCM 버전, 즉 CUCM 8.0(1) 이상을 기반으로 합니다.

참고: 기본적으로 보안(SBD)을 지원하는 전화기에만 해당됩니다. 예를 들어, 7940 및 7960 전화기는 SBD를 지원하지 않으며 7935, 7936 및 7937 전화기도 지원하지 않습니다. 사용 중인 CUCM 버전에서 SBD를 지원하는 디바이스 목록을 보려면 Cisco Unified Reporting > System Reports > Unified CM Phone Feature List로 이동하여 Feature: Security By Default에 대한 보고서를 실행하십시오.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

MIC 대 LSC

802.1X 또는 Anyconnect Phone VPN에 대해 인증서 기반 인증을 사용하는 경우 MIC와 LSC의 차이를 이해하는 것이 중요합니다.

모든 Cisco 전화기는 공장에 미리 설치된 MIC와 함께 제공됩니다. 이 인증서는 Cisco Manufacturing CA 인증서 중 하나(Cisco Manufacturing CA, Cisco Manufacturing CA SHA2, CAP-RTP-001 또는 CAP-RTP-002 인증서)에 의해 서명됩니다. 전화기에서 이 인증서를 제공할 때 유효한 Cisco 전화기임을 확인하지만, 해당 전화기가 특정 고객 또는 CUCM 클러스터에 속하는지 확인하지 않습니다. 이는 오픈 마켓에서 구입하거나 다른 사이트에서 가져온 악성 전화일 수 있습니다.

반면 LSC는 관리자가 의도적으로 전화기에 설치하고 CUCM 게시자의 CAPF 인증서로 서명합니다. 알려진 CAPF 인증 기관에서 발급한 LSC만 신뢰하도록 802.1X 또는 Anyconnect VPN을 구성할 수 있습니다. MIC 대신 LSC에서 인증서 인증을 기반으로 하면 신뢰할 수 있는 전화기 디바이스를 훨씬 더 세부적으로 제어할 수 있습니다.

구성

네트워크 토폴로지

이 문서에는 다음 CUCM 랩 서버가 사용되었습니다.

• ao115pub - 10.122.138.102 - CUCM 게시자 및 TFTP 서버
• ao115sub - 10.122.138.103 - CUCM 가입자 및 TFTP 서버 

CAPF 인증서가 만료되지 않았는지, 또는 가까운 장래에 만료되지 않았는지 확인합니다. Cisco Unified OS Administration(Cisco Unified OS 관리) > Security(보안) > Certificate Management(인증서 관리)로 이동한 다음 Find Certificate List where Certificate is exactly CAPF is as the image(이미지에 표시된 대로 인증서가 정확히 CAPF인 인증서 목록 찾기)로 이동합니다.

Certificate Details(인증서 세부사항) 페이지를 열려면 Common Name(일반 이름)을 클릭합니다. 이미지에 표시된 것처럼 인증서가 만료되는 시기를 확인하기 위해 Certificate File Data 창에서 Validity From: 및 To: 날짜를 검사합니다.

CAPF 인증서가 만료되었거나 곧 만료될 경우 해당 인증서를 다시 생성합니다. CAPF 인증서가 만료되었거나 곧 만료될 예정인 LSC 설치 프로세스를 진행하지 마십시오. 따라서 CAPF 인증서 만료로 인해 가까운 시일 내에 LSC를 재발급할 필요가 없습니다. CAPF 인증서를 재생하는 방법에 대한 자세한 내용은 CUCM Certificate Regeneration/Renewal Process 문서를 참조하십시오.

마찬가지로, 타사 인증 기관에서 서명한 CAPF 인증서가 필요한 경우 이 단계에서 선택할 수 있습니다. 서명된 CAPF 인증서의 CSR(Certificate Signing Request) 파일 생성 및 가져오기를 지금 완료하거나, 사전 테스트를 위해 자체 서명된 LSC를 사용하여 컨피그레이션을 계속합니다. 서명한 타사 CAPF 인증서가 필요한 경우, 일반적으로 자체 서명 CAPF 인증서로 이 기능을 먼저 구성하고 테스트하고 확인한 다음 서명한 타사 CAPF 인증서로 서명한 LSC를 재구축하는 것이 좋습니다. 이렇게 하면 서드파티 서명 CAPF 인증서와의 테스트가 실패할 경우 나중에 트러블슈팅이 간소화됩니다.

경고: CAPF 서비스가 활성화되고 시작되는 동안 CAPF 인증서를 다시 생성하거나 서드파티 서명된 CAPF 인증서를 가져오면 CUCM에서 전화기가 자동으로 재설정됩니다. 전화기를 재설정할 수 있는 경우 유지 관리 창에서 이 절차를 완료합니다. 자세한 내용은 Cisco 버그 ID CSCue55353 - Add Warning when Regenerate TVS/CCM/CAPF Certificate that Phones Reset을 참조하십시오.

참고: CUCM 버전에서 SBD를 지원하는 경우 CUCM 클러스터가 혼합 모드로 설정되어 있는지 여부에 관계없이 이 LSC 설치 절차가 적용됩니다. SBD는 CUCM 버전 8.0(1) 이상의 일부입니다. 이 버전의 CUCM에서는 ITL 파일에 CUCM 게시자의 CAPF 서비스에 대한 인증서가 포함됩니다. 따라서 설치/업그레이드 및 문제 해결과 같은 인증서 작업을 지원하기 위해 전화기가 CAPF 서비스에 연결할 수 있습니다.

이전 버전의 CUCM에서는 인증서 작업을 지원하기 위해 혼합 모드에 대한 클러스터를 구성해야 했습니다. 더 이상 필요하지 않으므로 802.1X 인증 또는 AnyConnect VPN 클라이언트 인증을 위한 폰 ID 인증서로 LSC를 사용하는 데 따르는 장벽이 줄어듭니다.

CUCM 클러스터의 모든 TFTP 서버에서 show itl 명령을 실행합니다. ITL 파일에 CAPF 인증서가 포함되어 있는지 확인합니다.

예를 들어, 랩 CUCM Subscriber ao115sub에서 실행한 show itl 출력의 일부입니다.

참고: 이 파일에는 CAPF 함수를 사용하는 ITL 레코드 항목이 있습니다.

참고: ITL 파일에 CAPF 항목이 없으면 CUCM 게시자에 로그인하여 CAPF 서비스가 활성화되었는지 확인합니다. 이를 확인하려면 Cisco Unified Serviceability(Cisco Unified 서비스 가용성) > Tools(툴) > Service Activation(서비스 활성화) > CUCM Publisher(CUCM 게시자) > Security(보안)로 이동한 다음 Cisco Certificate Authority Proxy Function Service(Cisco Certificate Authority 프록시 기능 서비스)를 활성화합니다. 서비스가 비활성화되었지만 방금 활성화한 경우 Cisco Unified Serviceability(Cisco Unified 서비스 가용성) > Tools(툴) > Control Center - Feature Services(제어 센터 - 기능 서비스) > Server(서버) > CM Services(CM 서비스)로 이동한 다음, CUCM 클러스터의 모든 TFTP 서버에서 Cisco TFTP 서비스를 다시 시작하여 ITL 파일을 다시 생성합니다. 또한 Cisco 버그 ID CSCuj78330을 치지 않아야 합니다.

참고: 이 작업을 완료한 후 현재 CUCM 게시자 CAPF 인증서가 파일에 포함되어 있는지 확인하기 위해 CUCM 클러스터의 모든 TFTP 서버에서 show itl 명령을 실행합니다.

 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.

CAPF 항목이 ITL의 항목으로 확인되면 전화기에서 인증서 작업을 완료할 수 있습니다. 이 예에서는 Null 문자열 인증을 사용하여 2048비트 RSA 인증서를 설치합니다.

전화기에서 이미지에 표시된 대로 LSC가 아직 설치되지 않았는지 확인합니다. 예를 들어, 79XX 시리즈 전화기에서 Settings(설정) > 4 - Security Configuration(4 - 보안 컨피그레이션) > 4 - LSC로 이동합니다.

전화기의 전화기 컨피그레이션 페이지를 엽니다. Cisco Unified CM Administration(Cisco Unified CM 관리) > Device(디바이스) > Phone(전화기)으로 이동합니다.

그림과 같이 전화기 컨피그레이션의 CAPF Information 섹션에 다음 세부 정보를 입력합니다.

• Certificate Operation(인증서 작업)에서 Install/Upgrade(설치/업그레이드)를 선택합니다.
• 인증 모드의 경우 By Null String을 선택합니다
• 이 예에서는 Key Order(키 순서), RSA Key Size(Bits)(RSA 키 크기(비트)) 및 EC Key Size(Bits)(EC 키 크기(비트))를 시스템 기본값으로 설정된 상태로 둡니다.
• Operation Completes By(작업 완료자)에 적어도 1시간 이상의 미래 날짜와 시간을 입력합니다.

컨피그레이션 변경 사항을 저장한 다음 컨피그레이션을 적용합니다.

전화기의 LSC 상태가 그림과 같이 Pending(보류 중)으로 변경됩니다.

전화기는 이미지에 표시된 대로 키를 생성합니다.

전화기가 재설정되고 재설정이 완료되면 이미지에 표시된 대로 전화기 LSC 상태가 Installed(설치됨)로 변경됩니다.

이 메시지는 그림과 같이 전화기의 상태 메시지에도 표시됩니다.

다음을 확인합니다.

구성이 올바르게 작동하는지 확인하려면 이 섹션을 활용하십시오.

여러 전화기에서 LSC 인증서 설치를 확인하려면 Security Guide for Cisco Unified Communications Manager, Release 11.0(1)의 Generate CAPF Report 섹션을 참조하십시오. 또는 LSC 상태별 전화기 찾기 또는 인증 문자열 절차를 사용하여 CUCM 관리 웹 인터페이스 내에서 동일한 데이터를 볼 수 있습니다.

전화기에 설치된 LSC 인증서의 복사본을 가져오려면 How to Retrieve Certificates from Cisco IP Phonesarticle을 참조하십시오.

문제 해결

이 섹션에서는 컨피그레이션 문제를 해결하는 데 사용할 수 있는 정보를 제공합니다.

유효한 CAPF 서버 없음

LSC가 설치되지 않습니다. 전화기의 상태 메시지에 유효한 CAPF 서버가 없습니다. 이는 ITL 파일에 CAPF 항목이 없음을 나타냅니다. CAPF 서비스가 활성화되었는지 확인한 다음 TFTP 서비스를 다시 시작합니다. 다시 시작한 후 ITL 파일에 CAPF 인증서가 포함되어 있는지 확인하고 전화기를 재설정하여 최신 ITL 파일을 선택한 다음 인증서 작업을 다시 시도하십시오. 전화기의 보안 설정 메뉴에 CAPF 서버 항목이 호스트 이름 또는 정규화된 도메인 이름으로 표시되는 경우 전화기가 해당 항목을 IP 주소로 확인할 수 있는지 확인합니다.

LSC: 연결 실패

LSC가 설치되지 않습니다. 전화기의 상태 메시지에는 LSC: Connection Failed(연결 실패)가 표시됩니다. 이는 다음 조건 중 하나를 나타낼 수 있습니다.

• ITL 파일의 CAPF 인증서와 현재 인증서가 일치하지 않으면 CAPF 서비스가 사용 중입니다.
• CAPF 서비스가 중지되거나 비활성화됩니다.
• 전화기가 네트워크를 통해 CAPF 서비스에 연결할 수 없습니다.

CAPF 서비스가 활성화되었는지 확인하고, CAPF 서비스를 다시 시작하고, 클러스터 전체에서 TFTP 서비스를 다시 시작하고, 전화기를 재설정하여 최신 ITL 파일을 선택한 다음 인증서 작업을 다시 시도하십시오. 문제가 지속되면 전화기와 CUCM 게시자에서 패킷 캡처를 가져온 다음 기본 CAPF 서비스 포트인 포트 3804에서 양방향 통신이 있는지 분석합니다. 그렇지 않은 경우 네트워크 문제가 발생할 수 있습니다.

LSC: 실패

LSC가 설치되지 않습니다. 전화기의 상태 메시지에는 LSC: Failed(LSC: 실패)가 표시됩니다. Phone Configuration(전화기 컨피그레이션) 웹 페이지에는 Certificate Operation Status(인증서 작업 상태): Upgrade Failed(업그레이드 실패): User Initiated Request Late/Timeout(사용자가 시작한 요청 지연/시간 초과)이 표시됩니다. 이는 작업 완료 시간 및 날짜가 만료되었거나 이전임을 나타냅니다. 적어도 1시간 이상 경과한 날짜와 시간을 입력하고 인증서 작업을 다시 시도하십시오.

LSC: 작업 보류 중

LSC가 설치되지 않습니다. 전화기의 상태 메시지에 LSC: Connection Failed(연결 실패)가 표시됩니다. Phone Configuration(전화기 컨피그레이션) 페이지에 Certificate Operation Status(인증서 작업 상태): Operation Pending(작업 보류 중)이 표시됩니다. Certificate Operation Status(인증서 작업 상태): Operation Pending status(작업 보류 중 상태)를 볼 수 있는 여러 가지 이유가 있습니다. 그 중 일부는 다음과 같습니다.

• 전화기의 ITL이 현재 혼동된 TFTP 서버에서 사용되는 것과 다릅니다.
• 손상된 ITL의 문제. 이 경우 디바이스는 신뢰할 수 있는 상태를 잃게 되며 전화기에서 이제 ITLRecovery 인증서를 사용하도록 강제하려면 CUCM 게시자에서 utils itl reset localkey 명령을 실행해야 합니다. 클러스터가 혼합 모드인 경우 utils ctl reset localkey 명령을 사용해야 합니다. 다음은 CUCM의 CLI에서 손상된 ITL을 보려고 할 때 표시되는 예입니다. ITL을 보고 utils itl reset localkey 명령을 실행하려고 할 때 오류가 있지만 두 번째 오류가 표시되는 경우 Cisco 버그 ID CSCus33755 결함일 수 있습니다. CUCM 버전이 영향을 받는지 확인합니다.

• TVS 오류로 인해 전화기가 새 LSC를 인증하지 못합니다.
• 전화기에서 MIC 인증서를 사용하지만 전화기 컨피그레이션 페이지의 CAPF(Certificate Authority Proxy Function) 정보 섹션에 Authentication Mode(인증 모드)가 Existing Certificate(LSC에 우선)로 설정되어 있습니다.
• 전화기에서 CUCM의 FQDN을 확인할 수 없습니다.

마지막 시나리오에서는 전화기가 CUCM의 FQDN을 확인할 수 없는 경우 로그에 표시되는 내용을 시뮬레이션하기 위해 랩 환경이 설정됩니다. 현재 이 실습에서는 다음 서버를 사용합니다.

• 버전 11.5.1.15038-2를 실행하는 CUCM 게시자 및 가입자
• Windows 2016 Server를 내 DNS 서버로 설정

테스트에는 구성된 PUB11 CUCM 서버에 대한 DNS 항목이 없습니다.

Lab의 전화기 중 하나(8845)에 LSC를 푸시하려고 했습니다. 여전히 Certificate Operation Status(인증서 작업 상태): Operation Pending(작업 보류 중)이 표시됩니다.

구성된 DNS 서버 주소로 쿼리를 전달하기 전에 전화기 콘솔 로그에서 해당 로컬 캐시(127.0.0.1)를 확인합니다.

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

아래의 전화기 상태 메시지에서 PUB11.brianw2.lab을 확인할 수 없음을 참조하십시오. 그런 다음 LSC: Connection failed(LSC: 연결 실패) 메시지를 확인합니다.

고려할 결함:

Cisco 버그 ID CSCub62243 - LSC 설치가 간헐적으로 실패하고 CAPF Server가 정지됨

고려할 개선 결함:

Cisco 버그 ID CSCuz18034 - 만료 상태와 함께 LSC 설치 엔드포인트에 대한 보고 필요

관련 정보

이 문서에서는 AnyConnect VPN 클라이언트 인증 및 802.1X 인증을 위한 컨텍스트에서 LSC를 사용하는 방법에 대한 자세한 정보를 제공합니다.

• AnyConnect VPN Phone - IP Phone, ASA 및 CUCM 문제 해결
• ID 기반 네트워킹 서비스: IEEE 802.1X 지원 네트워크 구축 및 구성 설명서의 IP 텔레포니

LSC 인증서는 CAPF 인증서가 아니라 서드파티 인증 기관에서 직접 서명하는 고급 유형의 LSC 컨피그레이션도 있습니다.

자세한 내용은 CUCM 서드파티 CA 서명 LSC 생성 및 가져오기 컨피그레이션 예를 참조하십시오.

• 기술 지원 및 문서 − Cisco Systems