CUCM의 인증서 및 권한에 대한 상위 레벨 보기

다운로드 옵션

PDF (345.4 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (389.5 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (715.5 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2013년 4월 8일

문서 ID:115957

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서의 목적은 인증서 및 인증 기관의 기본 사항을 이해하는 것입니다.이 문서는 CUCM(Cisco Unified Communications Manager)의 암호화 또는 인증 기능을 참조하는 다른 Cisco 문서를 보완합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

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

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

인증서의 용도

인증서는 엔드포인트 간에 데이터 신뢰/인증 및 암호화를 구축하는데 사용됩니다.이는 엔드포인트가 의도한 디바이스와 통신하며 두 엔드포인트 간의 데이터를 암호화하는 옵션이 있음을 확인합니다.

인증서의 관점에서 신뢰 정의

인증서의 가장 중요한 부분은 엔드포인트가 신뢰할 수 있는 엔드포인트를 정의하는 것입니다.이 문서는 의도된 웹 사이트, 전화, FTP 서버 등과 데이터를 암호화하고 공유하는 방법을 알고 정의하는 데 도움이 됩니다.

시스템이 인증서를 신뢰하는 경우, 시스템에 사전 설치된 인증서가 있음을 의미하며, 이 인증서는 정보를 올바른 엔드포인트와 공유한다고 100% 신뢰합니다.그렇지 않으면 이러한 엔드포인트 간의 통신이 종료됩니다.

이에 대한 비기술적 예는 운전면허증입니다.이 라이센스(서버/서비스 인증서)를 사용하여 자신이 누구인지 확인합니다.귀하는 주(인증 기관)의 자동차 사업부(DMV)로부터 허가를 받은 지역 자동차 지사(중간 인증서)로부터 면허를 받았습니다. 관리자에게 라이센스(서버/서비스 인증서)를 표시해야 할 경우, 관리자는 DMV 지사(중간 인증서) 및 Division of Motor(인증 기관)를 신뢰할 수 있음을 알고 있으며, 이 라이센스가 해당 직원(인증 기관)에서 발급되었음을 확인할 수 있습니다. 당신의 신원은 경찰관에게 확인되고, 이제 그들은 당신이 당신이 말하는 사람임을 믿습니다.그렇지 않은 경우 DMV(중간 인증서)에서 서명하지 않은 잘못된 라이센스(서버/서비스 인증서)를 부여하는 경우, 이들은 사용자가 말하는 사용자를 신뢰하지 않습니다.이 문서의 나머지 부분에서는 인증서 계층 구조에 대한 자세한 기술적 설명을 제공합니다.

브라우저에서 인증서를 사용하는 방법

웹 사이트를 방문할 때 http://www.cisco.com과 같은 URL을 입력합니다.
DNS는 해당 사이트를 호스팅하는 서버의 IP 주소를 찾습니다.
브라우저가 해당 사이트로 이동합니다.

인증서가 없으면 비인가 DNS 서버가 사용되었는지 또는 다른 서버로 라우팅되었는지 알 수 없습니다.인증서는 사용자가 입력한 개인 또는 민감한 정보가 안전한 은행 웹 사이트와 같은 의도된 웹 사이트로 올바르게 안전하게 라우팅되도록 합니다.

모든 브라우저에는 서로 다른 아이콘이 있지만 일반적으로 주소 표시줄에 다음과 같은 자물쇠가 표시됩니다.

자물쇠를 클릭하면 다음과 같은 창이 표시됩니다.
그림 1:웹 사이트 식별
View Certificates(인증서 보기)를 클릭하여 다음 예에 표시된 대로 사이트의 인증서를 확인합니다.
그림 2:인증서 정보, 일반 탭

강조 표시된 정보가 중요합니다.
- 발급자는 시스템이 이미 신뢰하는 회사 또는 CA(Certificate Authority)입니다.
- Valid from/to는 이 인증서를 사용할 수 있는 날짜 범위입니다.(경우에 따라 CA를 신뢰하는 인증서를 볼 수 있지만 인증서가 유효하지 않다는 것을 알 수 있습니다.만료되었는지 여부를 알 수 있도록 항상 날짜를 확인합니다.)
팁:가장 좋은 방법은 인증서가 만료되기 전에 인증서를 갱신하기 위한 미리 알림을 달력에 만드는 것입니다.이는 향후 문제를 방지합니다.

PEM과 DER 인증서의 차이점

PEM은 ASCII입니다.DER는 이진법입니다.그림 3은 PEM 인증서 형식을 보여줍니다.

그림 3:PEM 인증서 예

그림 4는 DER 인증서를 보여줍니다.

그림 4:DER 인증서 예

VeriSign 또는 Thawt와 같은 대부분의 CA 기업은 이메일을 통해 쉽게 인증서를 전송할 수 있으므로 PEM 형식을 사용하여 고객에게 인증서를 전송합니다.고객은 전체 문자열을 복사하고 —BEGIN CERTIFICATE— 및—END CERTIFICATE—를 포함하여 텍스트 파일에 붙여넣은 다음 .PEM 또는 .CER 확장명으로 저장해야 합니다.

Windows에서는 자체 Certificate Management Applet을 사용하여 DER 및 CER 형식을 읽을 수 있으며 그림 5와 같이 인증서를 표시합니다.

그림 5:인증서 정보

경우에 따라 디바이스에는 특정 형식(ASCII 또는 이진)이 필요합니다. 이를 변경하려면 필요한 형식으로 CA에서 인증서를 다운로드하거나 https://www.sslshopper.com/ssl-converter.html과 같은 SSL 변환기 도구를 사용합니다.

인증서 계층

엔드포인트에서 인증서를 신뢰하려면 서드파티 CA로 이미 설정된 트러스트가 있어야 합니다.예를 들어, 그림 6은 세 개의 인증서가 있는 계층을 보여줍니다.

그림 6:인증서 계층

Verisign은 CA입니다.
Verisign Class 3 Extended Validation SSL CA는 중간 또는 서명 서버 인증서(CA가 해당 이름으로 인증서를 발급하도록 인증한 서버)입니다.
www.website.com는 서버 또는 서비스 인증서입니다.

엔드포인트는 SSL 핸드셰이크가 제공하는 서버 인증서를 신뢰할 수 있음을 알기 전에 먼저 CA 및 중간 인증서를 모두 신뢰할 수 있음을 알아야 합니다(아래 세부 정보). 이 트러스트의 작동 방식을 자세히 알아보려면 이 문서의 섹션을 참조하십시오.인증서의 POV에서 "신뢰"를 정의합니다.

자체 서명 인증서 대 타사 인증서

자체 서명 인증서와 서드파티 인증서의 주요 차이점은 인증서를 신뢰하는지 여부에 관계없이 누가 서명했는가입니다.

자체 서명 인증서는 서버에서 서명한 인증서로서,따라서 서버/서비스 인증서와 CA 인증서가 동일합니다.

서드파티 CA는 공용 CA(Verisign, Entrust, Digicert 등) 또는 서버/서비스 인증서의 유효성을 제어하는 서버(예: Windows 2003, Linux, Unix, IOS)에서 제공하는 서비스입니다.

각 CA가 될 수 있습니다.시스템이 CA를 신뢰하는지 여부에 관계없이 가장 중요한 것은 입니다.

공통 이름 및 주체 대체 이름

CN(Common Names) 및 SAN(Subject Alternative Names)은 요청된 주소의 IP 주소 또는 FQDN(Fully Qualified Domain Name)에 대한 참조입니다.예를 들어, https://www.cisco.com을 입력하면 CN 또는 SAN은 헤더에 www.cisco.com이 있어야 합니다.

그림 7에 나와 있는 예에서 인증서는 CN을 www.cisco.com으로 합니다.브라우저에서 www.cisco.com에 대한 URL 요청은 인증서가 제공하는 정보와 비교하여 URL FQDN을 확인합니다.이 경우 SSL 핸드셰이크가 성공했음을 보여 줍니다.이 웹 사이트가 올바른 웹 사이트로 확인되었으며 이제 데스크톱과 웹 사이트 간에 통신이 암호화되었습니다.

그림 7:웹 사이트 확인

동일한 인증서에는 3개의 FQDN/DNS 주소에 대한 SAN 헤더가 있습니다.

그림 8:SAN 헤더

이 인증서는 www.cisco.com(CN에 정의됨), cisco.com 및 cisco-images.cisco.com을 인증/확인할 수 있습니다.즉, cisco.com을 입력할 수 있으며 이 인증서를 사용하여 이 웹 사이트를 인증하고 암호화할 수 있습니다.

CUCM은 SAN 헤더를 생성할 수 있습니다.SAN 헤더에 대한 자세한 내용은 Jason Burn의 문서, CUCM Uploading CCMAdmin 웹 GUI Certificates를 참조하십시오.

와일드카드 인증서

와일드카드 인증서는 URL의 섹션에 있는 임의의 문자열을 나타내기 위해 별표(*)를 사용하는 인증서입니다.예를 들어 www.cisco.com, ftp.cisco.com, ssh.cisco.com 등에 대한 인증서를 보유하려면 관리자는 *.cisco.com에 대한 인증서만 생성해야 합니다.비용을 절약하기 위해 관리자는 단일 인증서만 구매해야 하며 여러 인증서를 구매할 필요가 없습니다.

이 기능은 현재 CUCM(Cisco Unified Communications Manager)에서 지원되지 않습니다. 그러나 다음과 같은 개선 사항을 추적할 수 있습니다.CSCta14114:CUCM 및 개인 키 가져오기에서 와일드카드 인증서 지원을 요청합니다.

인증서 식별

인증서에 동일한 정보가 있는 경우 동일한 인증서인지 확인할 수 있습니다.모든 인증서에는 고유한 일련 번호가 있습니다.인증서가 동일한 인증서, 재생성 또는 위조인지 비교하는 데 사용할 수 있습니다.그림 9는 다음과 같은 예를 제공합니다.

그림 9:인증서 일련 번호

CSR 및 목적

CSR은 Certificate Signing Request를 의미합니다.CUCM 서버에 대한 서드파티 인증서를 생성하려면 CA에 CSR이 있어야 합니다.이 CSR은 PEM(ASCII) 인증서와 매우 유사합니다.

참고: 이 인증서는 인증서가 아니며 하나의 인증서로 사용할 수 없습니다.

CUCM은 웹 GUI를 통해 자동으로 CSR을 생성합니다.Cisco Unified Operating System Administration(Cisco Unified 운영 체제 관리) > Security(보안) > Certificate Management(인증서 관리) > Generate CSR(CSR 생성) > 인증서를 생성할 서비스를 선택한 다음 Generate CSR(CSR 생성)을 선택합니다.이 옵션을 사용할 때마다 새 개인 키와 CSR이 생성됩니다.

참고: 개인 키는 이 서버 및 서비스에 고유한 파일입니다.이것은 절대 누구에게도 주어져서는 안 된다!사용자에게 개인 키를 제공할 경우 인증서가 제공하는 보안을 손상시킵니다.또한 이전 CSR을 사용하여 인증서를 생성하는 경우 동일한 서비스에 대해 새 CSR을 재생성하지 마십시오.CUCM은 기존 CSR과 개인 키를 삭제하고 두 키를 모두 대체하므로 이전 CSR은 사용할 수 없습니다.

지원 커뮤니티에 대한 Jason Burn의 설명서를 참조하십시오.CUCM CSR 생성 방법에 대한 자세한 내용은 CCMAdmin 웹 GUI 인증서 업로드

엔드포인트와 SSL/TLS 핸드셰이크 프로세스 간 인증서 사용

핸드셰이크 프로토콜은 데이터 전송 세션의 보안 매개변수를 협상하는 일련의 시퀀스된 메시지입니다.핸드셰이크 프로토콜에서 메시지 시퀀스를 문서화하는 SSL/TLS의 세부사항을 참조하십시오.PCAP(패킷 캡처)에서 볼 수 있습니다. 세부 정보에는 클라이언트와 서버 간에 주고 받은 초기, 후속, 최종 메시지가 포함됩니다.

CUCM에서 인증서를 사용하는 방법

토마트와 토마트트러스트의 차이점

인증서가 CUCM에 업로드되면 Cisco Unified Operating System Administration(Cisco Unified 운영 체제 관리) > Security(보안) > Certificate Management(인증서 관리) > Find(찾기)를 통해 각 서비스에 대해 두 가지 옵션이 있습니다.

CUCM에서 인증서를 관리할 수 있는 다섯 가지 서비스는 다음과 같습니다.

고양이
ipsec
통화 관리자
카프
tvs(CUCM 릴리스 8.0 이상)

인증서를 CUCM에 업로드할 수 있는 서비스는 다음과 같습니다.

고양이
톰cat 트러스트
ipsec
ipsec 신뢰
통화 관리자
callmanager 트러스트
카프
capf 신뢰

다음은 CUCM 릴리스 8.0 이상에서 제공되는 서비스입니다.

TVS
tvs 신뢰
전화 신뢰
phone-vpn-trust
전화-신뢰
phone-ctl-trust

이러한 인증서 유형에 대한 자세한 내용은 릴리스별 CUCM 보안 가이드를 참조하십시오.이 섹션에서는 서비스 인증서와 신뢰 인증서의 차이점만 설명합니다.

예를 들어 tomcat을 사용하면 tomcat-trust는 CA 및 중간 인증서를 업로드하여 이 CUCM 노드가 CA 및 중간 서버에서 서명한 인증서를 신뢰할 수 있음을 인식합니다.tomcat 인증서는 엔드포인트가 이 서버에 HTTP 요청을 하는 경우 이 서버의 tomcat 서비스에서 제공하는 인증서입니다.tomcat에서 서드파티 인증서를 표시할 수 있도록 하려면 CUCM 노드가 CA 및 중간 서버를 신뢰할 수 있음을 알아야 합니다.따라서 tomcat(서비스) 인증서가 업로드되기 전에 CA 및 중간 인증서를 업로드해야 합니다.

CUCM에 인증서를 업로드하는 방법을 이해하는 데 도움이 되는 정보는 Jason Burn의 CUCM Uploading CCMAdmin 웹 GUI Certificates를 참조하십시오.

각 서비스에는 자체 서비스 인증서 및 트러스트 인증서가 있습니다.그들은 서로 어울리지 않는다.다시 말해, tomcat-trust 서비스로 업로드된 CA 및 중간 인증서는 callmanager 서비스에서 사용할 수 없습니다.

참고: CUCM의 인증서는 노드별로 사용됩니다.따라서 게시자에 인증서를 업로드해야 하고 가입자에게 동일한 인증서가 필요한 경우 CUCM 릴리스 8.5 이전의 각 개별 서버 및 노드에 인증서를 업로드해야 합니다. CUCM 릴리스 8.5 이상에는 업로드된 인증서를 클러스터의 나머지 노드에 복제하는 서비스가 있습니다.

참고: 각 노드에는 다른 CN이 있습니다.따라서 서비스가 자체 인증서를 표시하려면 각 노드에서 CSR을 생성해야 합니다.

CUCM 보안 기능에 대한 추가 특정 질문이 있는 경우 보안 설명서를 참조하십시오.

결론

이 문서는 인증서에 대한 높은 수준의 지식을 지원하고 구축합니다.이 제목은 더 심층적으로 설명될 수 있지만 이 문서에서는 인증서로 작업할 수 있을 정도로 친숙합니다.CUCM 보안 기능에 대한 질문이 있는 경우 자세한 내용은 CUCM Security Guides by Release를 참조하십시오.