본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.
Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.
이 문서에서는 Cisco CUCM(Unified Communications Manager) 릴리스 8.x 이상에서 사용되는 인증서를 재생성하는 방법에 대해 설명합니다. SBD(Security by Default) 기능에 따라 활성화된 ITL(Identity Trust List)과 혼합 모드 환경에 대한 CTL(Certificate Trust List)도 이 문서에서 다루어 불필요한 중단을 방지합니다. 예를 들어, 컨피그레이션 변경 또는 펌웨어를 수락하지 않는 전화 등록 문제 또는 전화를 방지하는 방법.
주의: 유지 관리 창에서 항상 인증서 재생성을 완료하는 것이 좋습니다.
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
이 문서의 정보는 다음 소프트웨어 버전을 기반으로 합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 이해해야 합니다.
새로 설치한 후 CUCM에 사용되는 대부분의 인증서는 기본적으로 5년간 자체 서명 인증서를 발급합니다. 현재 5년 시간 범위는 CUCM에서 더 짧은 시간 범위로 수정할 수 없습니다. 그러나 CA(Certificate Authority)는 거의 모든 시간 동안 인증서를 발급할 수 있습니다.
CUCM의 인증서는 두 가지 역할로 분류됩니다.
또한 사전 로드되고 유효 기간이 더 긴 신뢰할 수 있는 인증서(예: CAPF-trust 및 CallManager-trust)가 있습니다. 예를 들어, Cisco Manufacturing CA 인증서는 특정 기능에 대한 CUCM 신뢰 저장소에 제공되며 2029년까지 만료되지 않습니다.
인증서가 만료되기 전에 재생성해야 합니다. 인증서가 만료될 예정이면 RTMT(Syslog Viewer)에서 경고를 수신하고 알림이 구성된 이메일이 전송됩니다.
CUCM01.der 인증서를 5월 19일 월요일 신뢰 저장소 tomcat-trust의 서버 CUCM02 14:46에 만료하는 인증서 만료 알림의 예는 다음과 같습니다.
At Fri Sep 05 02:00:56 CEST 2014 on node 192.168.1.2, the following
SyslogSeverityMatchFound events generated:
SeverityMatch : Critical
MatchedEvent : Sep 5 02:00:06 CUCM02 local7 2 : 864: CUCM02.localdomain:
Sep 05 2014 00:00:06.433 UTC : %UC_CERT-2-CertValidfor7days:
%[Message=Certificate expiration Notification. Certificate name:CUCM01.der
Unit:tomcat-trust Type:own-cert Expiration:Mon May 19 14:46:]
[AppID=Cisco Certificate Monitor][ClusterID=][NodeID=CUCM02]:
Alarm to indicate that Certificate has Expired or Expires in less than seven days
AppID : Cisco Syslog Agent
ClusterID :
NodeID : CUCM02
TimeStamp : Fri Sep 05 02:00:16 CEST 2014
만료된 인증서는 클러스터의 구성에 따라 CUCM 기능에 영향을 줄 수 있습니다. 고려 사항은 다음 섹션에서 설명합니다.
CUCM 클러스터 전체에서 모든 인증서가 업데이트되는 것은 시스템의 우수한 기능에 중요합니다. 인증서가 만료되었거나 유효하지 않은 경우 시스템의 정상 기능에 큰 영향을 미칠 수 있습니다. 특정 인증서가 유효하지 않거나 만료되었을 때 발생할 수 있는 잠재적 문제 목록이 여기에 표시됩니다. 영향의 차이는 시스템 설정에 따라 달라질 수 있습니다.
CallManager.pem
톰cat.pem
CAPF.pem
IPSec.pem
TVS(Trust Verification Service)
전화기에서 HTTPS 서비스를 인증할 수 없습니다. 전화기에서 구성 파일을 인증할 수 없습니다(CUCM의 거의 모든 항목에 영향을 줄 수 있음).
phone-vpn-trust
VPN의 HTTPS URL을 인증할 수 없으므로 전화 VPN이 작동하지 않습니다.
참고: 만약 이것이 존재하지 않는다면 걱정하지 마세요. 이는 특정 컨피그레이션에만 적용됩니다.
전화-신뢰
이전 CTL/eTokens에서 CTL을 업데이트하거나 수정할 수 없습니다.
참고: 만약 이것이 존재하지 않는다면 걱정하지 마세요. 이는 특정 컨피그레이션에만 적용됩니다.
phone-trust 및 phone-ctl-trust
Unity 또는 Unity Connection이 포함된 비주얼 음성 메일이 작동하지 않습니다.
참고: 만약 이것이 존재하지 않는다면 걱정하지 마세요. 이는 특정 컨피그레이션에만 적용됩니다.
LSC 및 MIC
전화기가 등록되지 않거나 전화기에서 Phone VPN, Phone Proxy 또는 802.1x에 대해 인증되지 않습니다.
참고: MIC는 기본적으로 대부분의 전화기 모델에 있습니다. LSC는 CAPF에 의해 서명되며 기본적으로 지난 5년간 서명됩니다. CIPC(Cisco IP Communicator) 및 Jabber와 같은 소프트웨어 클라이언트에는 MIC가 설치되어 있지 않습니다.
이와 같은 주요 변경 사항을 수행하기 전에 DRS 백업을 생성하는 것이 좋습니다. CUCM DRF 백업 파일은 클러스터의 모든 인증서를 백업합니다. 모든 DRS 백업/복원 절차는 Cisco Unified Communications Manager용 Cisco Disaster Recovery System 관리 가이드에서 찾을 수 있습니다.
주의: Cisco 버그 ID CSCtn50405에 유의하십시오. CUCM DRF 백업은 인증서를 백업하지 않습니다.
CTL/Secure/Mixed-Mode 클러스터를 실행하는지 확인하려면 Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Non-Secure; 1 == 혼합 모드).
혼합 모드에서 CUCM 클러스터를 실행하는 경우 모든 인증서가 변경된 후 CTL 파일을 업데이트해야 합니다. 이 작업을 수행하는 방법에 대한 절차는 Cisco의 보안 설명서 내에 있습니다. 그러나 혼합 모드 기능의 원래 시작에서 하나 이상의 eToken이 있고 eToken 비밀번호가 알려졌는지 확인하십시오.
참고: CTL의 업데이트는 자동으로 수행되지 않습니다(ITL 파일의 경우와 마찬가지로). 관리자가 CTL Client 또는 CLI 명령을 사용하여 수동으로 완료해야 합니다.
CUCM 10.X 이상에서는 다음 두 가지 방법으로 클러스터를 혼합 모드로 전환할 수 있습니다.
admin:show ctl
The checksum value of the CTL file:
0c05655de63fe2a042cf252d96c6d609(MD5)
8c92d1a569f7263cf4485812366e66e3b503a2f5(SHA1)
Length of CTL file: 4947
The CTL File was last modified on Fri Mar 06 19:45:13 CET 2015
[...]
CTL Record #:1
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1156
2 DNSNAME 16 cucm-1051-a-pub
3 SUBJECTNAME 62 CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
ST=Malopolska;C=PL
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 62 CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
ST=Malopolska;C=PL
6 SERIALNUMBER 16 70:CA:F6:4E:09:07:51:B9:DF:22:F4:9F:75:4F:C5:BB
7 PUBLICKEY 140
8 SIGNATURE 128
9 CERTIFICATE 694 E9 D4 33 64 5B C8 8C ED 51 4D 8F E5 EA 5B 6D 21
A5 A3 8C 9C (SHA1 Hash HEX)
10 IPADDRESS 4
This etoken was used to sign the CTL file.
admin:show ctl
The checksum value of the CTL file:
256a661f4630cd86ef460db5aad4e91c(MD5)
3d56cc01476000686f007aac6c278ed9059fc124(SHA1)
Length of CTL file: 5728
The CTL File was last modified on Fri Mar 06 21:48:48 CET 2015
[...]
CTL Record #:5
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1186
2 DNSNAME 1
3 SUBJECTNAME 56 cn="SAST-ADN008580ef ";ou=IPCBU;o="Cisco Systems
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 42 cn=Cisco Manufacturing CA;o=Cisco Systems
6 SERIALNUMBER 10 83:E9:08:00:00:00:55:45:AF:31
7 PUBLICKEY 140
9 CERTIFICATE 902 85 CD 5D AD EA FC 34 B8 3E 2F F2 CB 9C 76 B0 93
3E 8B 3A 4F (SHA1 Hash HEX)
10 IPADDRESS 4
This etoken was used to sign the CTL file.
참고: Tokenless CTL과 함께 CUCM 혼합 모드에 사용된 방법 간에 이동할 수 있습니다.
클러스터를 보호하는 데 사용되는 방법에 따라 적절한 CTL 업데이트 절차를 사용해야 합니다. CTL 클라이언트를 다시 실행하거나 CLI에서 utils ctl update CTLfile 명령을 입력합니다.
ITL 문제는 많은 기능이 실패하거나 전화기에서 구성 변경 사항을 준수하지 않을 수 있으므로 피하는 것이 중요합니다. ITL 문제는 이 두 가지 방법으로 피할 수 있습니다.
이 기능은 ITL 파일의 ITL 항목을 제외하므로 전화기에서 모든 TFTP 서버를 신뢰합니다. 이 매개 변수가 True로 설정된 동안 전화기에서/받는 전화기에서 HTTPS 요청이 실패합니다. 내선 이동, 회사 디렉터리 등의 전화 기능을 제한하므로 이 기능을 활성화하지 않는 것이 좋습니다. 그러나 기본 전화 통화를 걸고 받을 수 있습니다.
참고: 이 매개변수는 CTL 항목이 아니라 ITL만 지우므로 혼합 모드 클러스터에서는 이 기능이 작동하지 않습니다.
참고: 이 기능은 ITL 문제를 방지하지만 해결하지 않습니다. 문제가 이미 전화기에 있는 경우 ITL을 제거하지 않고 ITL을 수동으로 제거해야 합니다.
참고: 이 매개변수를 변경하면 모든 전화기가 재설정됩니다.
이 기능이 설정되면 모든 TFTP 서버를 다시 시작해야 합니다(새 ITL을 제공하려면). 새 빈 ITL을 요청하도록 모든 전화기를 재설정해야 합니다. 인증서 변경이 완료되고 필요한 모든 서비스가 다시 시작되면 이 기능을 False로 다시 설정하고, TFTP 서비스를 다시 시작하며, 전화기 재설정을 통해 전화기가 유효한 ITL 파일을 가져올 수 있습니다. 그런 다음 모든 기능이 이전과 마찬가지로 계속 작동합니다.
이 절차에서는 사용 가능한 신뢰할 수 있는 TFTP 서버의 유효한/업데이트된 ITL 파일을 TFTP 서버에 제공합니다.
주의: 두 TFTP 서버에서 동시에 인증서를 편집하지 마십시오. 이렇게 하면 전화기를 신뢰할 TFTP 서버가 없으며 로컬 관리자가 모든 전화기에서 ITL을 수동으로 제거해야 합니다.
이는 가장 많이 사용되는 절차이며, 전화기가 신뢰를 잃게 하는 것을 방지하기 위해 권장되는 절차입니다. 이 프로세스는
Cisco CUCM(Unified Communications Manager)용 인증서 재생성 프로세스 가이드.
서비스 인증서(-trust로 레이블이 지정되지 않은 인증서 저장소)만 다시 생성할 수 있습니다. 신뢰 저장소의 인증서(-trust로 레이블이 지정된 인증서 저장소)는 다시 생성할 수 없으므로 삭제해야 합니다.
주의: Cisco 버그 ID CSCut58407 - CAPF/CallManager/TVS-trust가 제거되면 디바이스를 다시 시작하지 않아야 합니다.
모든 인증서를 수정한 후 변경 사항을 적용하려면 각 서비스를 다시 시작해야 합니다. 이는 After Regeneration /Removal of Certificates 섹션에서 다룹니다.
주의: Cisco 버그 ID CSCto86463 - 삭제된 인증서가 다시 나타나며 CUCM에서 인증서를 제거할 수 없습니다. 삭제된 인증서는 제거 후에도 계속 다시 나타나는 문제입니다. 결함의 해결 방법을 따릅니다.
주의: 인증서 재생성은 클러스터 내에서 ITL 파일의 자동 업데이트를 트리거하며, 이는 전화기가 로컬 ITL의 업데이트를 트리거할 수 있도록 클러스터 전체 소프트폰 재설정을 트리거합니다. CAPF 및 CallManager 인증서 재생성에 중점을 두지만 Tomcat과 같은 CUCM 내의 다른 인증서 저장소에서 발생할 수 있습니다.
CAPF 다시 생성: 재생성 시 CAPF 인증서는 자동으로 CAPF-trust 및 CallManager-trust에 업로드됩니다. 또한 CAPF에는 항상 고유한 Subject Name 헤더가 있으므로 이전에 사용한 CAPF 인증서가 보존되어 인증에 사용됩니다.
set cert regen CAPF
참고: CAPF 인증서가 만료되면 CUCM이 인증서를 거부하므로 LSC를 사용하는 전화기는 CUCM에 등록할 수 없습니다. 그러나 새 CAPF 인증서를 사용하여 전화기에 대해 새 LSC를 생성할 수 있습니다. 전화기를 재부팅하면 컨피그레이션이 다운로드되고 CAPF에 연결하여 LSC를 업데이트합니다. LSC가 업데이트되면 전화기가 정상적으로 등록됩니다. 이 작업은 새 CAPF 인증서가 ITL 파일에 있고 전화기가 다운로드한 후 서명한 인증서(callmanager.pem)를 신뢰하는 한 작동합니다.
CallManager 다시 생성: 재생성 시 CallManager는 자동으로 CallManager-trust에 업로드됩니다.
set cert regen CallManager
IPsec 다시 생성: 재생성 시 IPsec 인증서는 자동으로 ipsec-trust에 업로드됩니다.
set cert regen ipsec
Tomcat 다시 생성: 재생성 시 Tomcat 인증서가 tomcat-trust에 자동으로 업로드됩니다.
set cert regen tomcat
TVS 다시 생성:
set cert regen TVS
CLI를 통해 인증서를 재생성할 때 이 변경 사항을 확인하라는 메시지가 표시됩니다. yes를 입력한 다음 Enter를 선택합니다.
admin:set cert regen CAPF
WARNING: This operation will overwrite any CA signed certificate previously imported
for CAPF
Proceed with regeneration (yes|no)? yes
Successfully Regenerated Certificate for CAPF.
You must restart services related to CAPF for the regenerated certificates to become active.
CAPF-trust 인증서 제거
set cert delete CAPF <name of certificate>.pem
CallManager-trust 인증서 제거
set cert delete CallManager <name of certificate>.pem
ipsec-trust 인증서 제거
set cert delete ipsec <name of certificate>.pem
Tomcat-trust 인증서 제거
set cert delete tomcat <name of certificate>.pem
TVS-trust 인증서 제거
set cert delete TVS <name of certificate>.pem
CAPF 다시 생성:
재생성 시 CAPF 인증서는 자동으로 CAPF-trust 및 CallManager-trust에 업로드됩니다. 또한 CAPF 인증서에는 항상 고유한 Subject Name 헤더가 있으므로 이전에 사용한 CAPF 인증서가 보존되고 인증에 사용됩니다.
OS Admin > Security > Certificate Management > Find > Click CAPF certificate > Regenerate
CallManager 다시 생성:
재생성 시 CallManager 인증서가 자동으로 CallManager-trust에 업로드됩니다.
OS Admin > Security > Certificate Management > Find > Click CallManager certificate > Regenerate
IPsec 다시 생성:
재생성 시 IPsec 인증서는 자동으로 ipsec-trust에 업로드됩니다.
OS Admin > Security > Certificate Management > Find > Click ipsec certificate > Regenerate
Tomcat 다시 생성:
재생성 시 Tomcat 인증서가 tomcat-trust에 자동으로 업로드됩니다.
OS Admin > Security > Certificate Management > Find > Click tomcat certificate > Regenerate
TVS 다시 생성:
OS Admin > Security > Certificate Management > Find > Click TVS certificate > Regenerate
OS Admin > Security > Certificate Management > Find > Click X certificate within the
'-trust' store > Remove/Delete
인증서 저장소에서 인증서를 제거 또는 재생성한 후 변경 사항을 적용하려면 각 서비스를 재시작해야 합니다.
매장 | 다시 시작할 서비스 | 방법 |
토마트 | 토마트 | CLI: utils 서비스 재시작 Cisco Tomcat 해당되는 경우 CCX 환경에서 필요한 단계를 수행합니다. |
통화 관리자 | 통화 관리자; TFTP; CTIM관리자 | 웹 GUI: Cisco Unified Serviceability > Tools > Control Center - Feature Services > (Select Server)로 이동합니다. Cisco CallManager에서 Restart를 클릭합니다. 웹 GUI: Cisco Unified Serviceability > Tools > Control Center - Feature Services > (Select Server)로 이동합니다. Cisco Tftp에서 Restart를 클릭합니다. 웹 GUI: Cisco Unified Serviceability > Tools > Control Center - Feature Services > (Select Server)로 이동합니다. Cisco CTIManager에서 Restart를 클릭합니다. |
CAPF | CAPF(게시자에만 해당) | 웹 GUI: Cisco Unified Serviceability(Cisco Unified 서비스 가용성) > Tools(툴) > Control Center - Feature Services(제어 센터 - 기능 서비스) > (Select Server(서버 선택))로 이동합니다. Cisco Certificate Authority Proxy Function(Cisco 인증 기관 프록시 기능)에서 Restart(재시작)를 클릭합니다. |
TVS | 신뢰 확인 서비스(각 서버에 있음) | 웹 GUI: Cisco Unified Serviceability > Tools > Control Center - Network Services > (Select Server)로 이동합니다. Cisco Trust Verification Service(Cisco Trust Verification Service)에서 Restart(재시작)를 클릭합니다. |
ipsec | Cisco DRF Local(모든 노드에서); Cisco DRF Master(게시자) | CLI: utils 서비스 재시작 Cisco DRF 로컬 CLI: utils 서비스 재시작 Cisco DRF Master |
신뢰 저장소에서 만료된 인증서를 삭제하기 전에 사용 중인 인증서 및 사용 되지 않은 인증서를 식별해야 합니다. 삭제해야 하는 인증서를 선택하려면 다음 사항에 유의하십시오.
CAP-RTP-001
CAP-RTP-002
Cisco 루트 CA 2048
Cisco 루트 CA M2
ACT2_SUDI_CA
Cisco_Manufacturing_CA
Cisco_Manufacturing_CA_SHA2
CAPF 인증서가 재생성된 경우 클러스터의 모든 전화기에 대한 LSC 인증서를 새 CAPF 인증서에 의해 서명된 LSC로 업데이트해야 합니다.
전화기에서 LSC 설치에 문제가 있는 경우 전화기에서 다음 작업을 완료합니다.
전화기가 재설정되면 물리적 전화기에서 Settings(설정) > (6) Security Configuration(보안 컨피그레이션) > (4) LSC > **#(이 작업을 통해 GUI의 잠금을 해제하고 다음 단계로 진행할 수 있음) > Update(이전 단계를 수행할 때까지 업데이트가 표시되지 않음)로 이동합니다. 이제 Submit(제출)을 클릭합니다.
무선 전화(7921/25)가 아닌 경우 전화기에 인증서를 할당하지 마십시오. 무선 전화기는 자신을 인증하기 위해 서드파티 CA(Certificate Authority)를 사용합니다.
Cisco CUCM(Unified Communications Manager)의 인증서 재생성 프로세스: 이 설명서에서는 유형별 인증서를 재생성하는 프로세스, 가장 많이 사용되었으며 권장되는 프로세스에 대해 설명합니다.
CUCM 12.x 이상에서 ITLRecovery에 대한 인증서 재생성 프로세스: 이 설명서에서는 12.x CUCM 클러스터에서 ITLRecovery 인증서를 재생성하는 프로세스에 대해 설명합니다.
CUCM CA 서명 인증서의 재생성: 이 설명서에서는 CUCM에서 CA 서명 인증서의 프로세스 및 인증서를 업로드할 때 표시되는 가장 일반적인 오류에 대해 설명합니다.
CA 서명 다중 서버 주체 대체 이름 구성을 사용하는 Unified Communication 클러스터 설정 예: 이 가이드에서는 Tomcat Multi-san 인증서 재생성의 예를 제공합니다.
Unified Communications Manager IM & Presence Service 자체 서명 인증서 다시 생성: 이 설명서에서는 IM&P 노드에 대해 재생성 프로세스 및 재시작할 서비스를 제공합니다.
UCCX 솔루션 인증서 관리 가이드: 이 설명서에서는 UCCX의 인증서에 대한 통합 요구 사항과 인증서를 재생성하는 프로세스를 제공합니다.
Expressway C 및 E 재생성 프로세스는 다음 비디오에 설명되어 있습니다.
Expressway-C와 Expressway-E 간의 인증서 신뢰 구성 방법
문제가 발생하거나 이 절차에 도움이 필요한 경우 Cisco TAC(Technical Assistance Center)에 문의하십시오. 이 경우 TAC에서 다른 방법을 통해 서비스를 복원할 수 없는 경우 서비스를 복원하기 위해 DRF 백업을 마지막 수단으로 사용되므로 사용 가능한 상태로 유지합니다.
개정 | 게시 날짜 | 의견 |
---|---|---|
2.0 |
28-Oct-2021 |
이 문서에는 다른 인증서 갱신 문서가 포함되어 있습니다. |
1.0 |
21-Apr-2016 |
최초 릴리스 |