MRA(Collaboration Edge) 인증서 구성 및 문제 해결
목차
소개
이 문서에서는 MRA(Mobile Remote Access) 구축과 관련된 인증서를 설명합니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
배경 정보
공용 및 개인 인증 기관(CA)
Expressway-C 및 E 서버에서 인증서를 서명하는 여러 옵션이 있습니다.GoDaddy, Verisign 등 공용 CA에서 CSR(Certificate Signing Request)을 서명하도록 선택하거나 자체 CA(Certificate Authority)를 사용하여 내부적으로 서명할 수 있습니다(openSSL을 사용하여 자체 서명하거나 Microsoft Windows 서버와 같은 내부 엔터프라이즈 CA). 이러한 방법을 사용하여 CSR을 생성하고 서명하는 방법에 대한 자세한 내용은 VCS(Video Communication Server) 인증서 생성 가이드를 참조하십시오.
공용 CA에서 서명해야 하는 유일한 서버는 Expressway-E입니다. 이는 클라이언트가 MRA를 통해 노래할 때 인증서를 볼 수 있는 유일한 서버이므로 공용 CA를 사용하면 사용자가 수동으로 인증서를 수락하지 않아도 됩니다. 내부 CA를 사용하여 Expressway-E에 서명하면 작동하지만, 사용자는 신뢰할 수 없는 인증서를 수락하라는 메시지가 처음 표시됩니다.7800 및 8800 시리즈 전화기의 MRA 등록은 해당 인증서 신뢰 목록을 수정할 수 없으므로 내부 인증서도 작동하지 않습니다. 간단히 말해, Expressway-C 및 Expressway-E 인증서는 모두 동일한 CA에서 서명하는 것이 좋습니다. 그러나 두 서버에서 모두 신뢰할 수 있는 CA 목록을 올바르게 구성한 경우 이 요구 사항은 아닙니다.
인증서 체인 작동 방식
인증서는 서버 인증서에 서명한 소스를 확인하는 데 사용되는 둘 이상의 체인으로 연결됩니다. 체인에 세 가지 유형의 인증서, 즉 클라이언트/서버 인증서, 중간 인증서(경우에 따라), 루트 인증서(루트 CA라고도 함)가 있으며, 이는 인증서를 서명한 최상위 권한 인증서입니다.
인증서에는 체인을 구축하는 두 개의 기본 필드, 즉 제목과 발급자가 포함됩니다. 제목은 이 인증서가 나타내는 서버 또는 기관의 이름입니다. Expressway-C 또는 Expressway-E(또는 기타 UC) 디바이스의 경우, 이는 FQDN(Fully Qualified Domain Name)에서 구축됩니다. 발급자는 특정 인증서를 검증한 기관입니다. 누구나 인증서를 만든 서버(자체 서명 인증서라고도 하는 인증서 포함)에 서명할 수 있으므로 서버와 클라이언트는 신뢰할 수 있는 발급자 또는 CA 목록을 가지고 있습니다.
인증서 체인은 항상 자체 서명 최상위 또는 루트 인증서로 끝납니다. 인증서 계층 구조를 통해 이동할 때 제목과 관련하여 서로 다른 발급자가 있는 각 인증서는 주체 및 발급자가 일치하는 루트 CA를 보게 됩니다. 이는 최상위 인증서이므로 클라이언트 또는 서버의 신뢰할 수 있는 CA 목록에서 신뢰해야 하는 인증서임을 나타냅니다.
SSL 핸드셰이크 요약
키 교환 및 생성 등 패킷 캡처를 볼 때 유용할 수 있는 SSL 핸드셰이크 프로세스의 자세한 신호 흐름에 대한 자세한 신호 흐름은 이 플로우 다이어그램을 볼 수 있습니다. 접근 영역의 경우 Expressway-C는 항상 클라이언트 역할을 하며 Expressway-E는 항상 서버가 됩니다. 간소화된 Exchange는 다음과 같이 작동합니다.
Expressway-C Expressway-E
—클라이언트 hello—>
<—서버 hello—
<—서버 인증서—
<—인증서 요청—
—클라이언트 인증서—>
Expressway-C는 항상 연결을 시작하므로 항상 클라이언트이므로 Expressway-E는 인증서를 보낸 첫 번째 키입니다. Expressway-C에서 이 인증서를 검증할 수 없는 경우 핸드셰이크를 해체하고 Expressway-E에 자체 인증서를 보내지 않습니다.
또 다른 중요한 점은 인증서의 TLS(Transport Layer Security) 웹 클라이언트 인증 및 TLS 웹 서버 인증 특성입니다. 이러한 특성은 CSR에 서명하는 CA에서 결정되며(Windows CA를 사용하는 경우 선택한 템플릿에 의해 결정됨), 인증서가 클라이언트 또는 서버(또는 둘 다) 역할에서 유효한지 여부를 나타냅니다. VCS 또는 Expressway의 경우 상황에 따라(통과 영역의 경우 항상 동일함) 인증서가 클라이언트 및 서버 인증 특성을 모두 가져야 합니다. Expressway-C와 Expressway-E는 새 서버 인증서를 업로드할 때 둘 다 적용되지 않은 경우 오류를 표시합니다.
인증서에 이러한 특성이 있는지 확실하지 않은 경우 브라우저 또는 OS에서 인증서 세부 정보를 열고 Extended Key Usage(확장 키 사용) 섹션을 확인할 수 있습니다(스크린샷 참조). 형식은 다를 수 있으며 인증서를 보는 방법에 따라 다릅니다.예:
구성
Expressway-C 및 Expressway-E Traversal Zone/Trust
CSR 생성 및 서명
앞에서 설명한 대로 Expressway-C 및 Expressway-E 인증서는 내부 또는 외부 CA에서 서명하거나, openSSL을 사용하여 자체 서명해야 합니다. Expressway 서버에 제공된 임시 인증서를 사용할 수 없습니다. CA가 서명되어 있는 와일드카드 인증서(제목 줄이 특별히 정의되지 않은 인증서)를 사용하는 것도 지원되지 않습니다.
첫 번째 단계는 CSR을 생성하고 기본 CA 유형으로 서명하는 것입니다. 이 프로세스는 인증서 생성 가이드에 특별히 설명되어 있습니다. CSR을 생성하는 동안 인증서에 포함해야 하는 필수 SAN(Subject Alternative Name)을 염두에 두어야 합니다.인증서 가이드 및 Mobile Remote Access 구축 가이드에도 나와 있습니다. 새 기능이 도착하면 최신 버전의 가이드를 참조하십시오. 사용된 기능에 따라 포함해야 하는 공통 SAN 목록:
Expressway-C
- 도메인 목록에 추가된 모든 도메인(내부 또는 외부)
- XMPP 통합을 사용하는 경우 영구 채팅 노드 별칭
- 보안 디바이스 프로필을 사용하는 경우 CUCM에서 디바이스 프로필 이름을 보호합니다.
Expressway-E
- Expressway-C에 구성된 모든 도메인
- XMPP 통합을 사용하는 경우 영구 채팅 노드 별칭
- XMPP 연합에 대해 광고되는 모든 도메인.
서로 신뢰하도록 Expressway-C 및 Expressway-E 구성
Unified Communications 접근 영역에서 연결을 설정하려면 Expressway-C 및 Expressway-E가 다른 인증서를 신뢰해야 합니다. 이 예에서는 공용 CA에서 다음 계층 구조를 사용하여 Expressway-E 인증서를 서명했다고 가정합니다.
인증서 3
발급자:GoDaddy 루트 CA
제목:GoDaddy 루트 CA
인증서 2
발급자:GoDaddy 루트 CA
제목:GoDaddy 중간 기관
인증서 1
발급자:GoDaddy 중간 기관
제목:Expressway-E.lab.com
Expressway-C는 위의 신뢰 인증서 1로 구성해야 합니다. 대부분의 경우 서버에 적용된 신뢰할 수 있는 인증서가 실제로 인증서를 전송한 경우에 따라 해당 서버는 가장 낮은 수준의 서버 인증서만 전송합니다. 즉, Expressway-C가 인증서 1을 신뢰하려면 인증서 2와 3을 모두 Expressway-C의 신뢰할 수 있는 CA 목록(Maintenance> Security > Trusted CA List)에 업로드해야 합니다. 중간 인증서 2를 제외하고 Expressway-C가 Expressway-E 인증서를 받을 때 Expressway-C는 이를 신뢰할 수 있는 GoDaddy 루트 CA에 연결할 수 없으므로 거부됩니다.
인증서 3
발급자:GoDaddy 루트 CA
제목:GoDaddy 루트 CA
인증서 1
발급자: GoDaddy 중간 관리자 - 신뢰할 수 없음!
제목:Expressway-E.lab.com
또한 루트 없이 Expressway-C의 신뢰할 수 있는 CA 목록에 중간 인증서만 업로드하면 GoDaddy Intermediate Authority가 신뢰되지만 상위 권한, 신뢰할 수 없는 GoDaddy Root CA에 의해 서명되므로 실패합니다.
인증서 2
발급자: GoDaddy 루트 CA - 신뢰할 수 없음!
제목:GoDaddy 중간 기관
인증서 1
발급자:GoDaddy 중간 기관
제목:Expressway-E.lab.com
모든 중간 및 루트가 신뢰할 수 있는 CA 목록에 추가되어 인증서를 확인할 수 있습니다.
인증서 3
발급자:GoDaddy Root CA - 자체 서명된 최상위 인증서가 신뢰되며 체인이 완료되었습니다!
제목:GoDaddy 루트 CA
인증서 2
발급자:GoDaddy 루트 CA
제목:GoDaddy 중간 기관
인증서 1
발급자:GoDaddy 중간 기관
제목:Expressway-E.lab.com
인증서 체인이 무엇인지 알 수 없는 경우 특정 Expressway의 웹 인터페이스에 로그인할 때 브라우저를 확인할 수 있습니다. 이 프로세스는 브라우저에 따라 약간 다르지만, Firefox에서는 주소 표시줄 왼쪽에 있는 잠금 아이콘을 클릭할 수 있습니다. 그런 다음 팝업에서 More Information(추가 정보) > View Certificate(인증서 보기) > Details(세부사항)를 클릭합니다. 브라우저가 전체 체인을 하나로 묶을 수 있다고 가정할 경우, 상위에서 하단으로 체인이 표시됩니다. 최상위 인증서에 일치하는 주체 및 발급자가 없는 경우 전체 체인이 표시되지 않음을 알 수 있습니다. 원하는 인증서를 강조 표시한 상태로 내보내기를 클릭하여 체인의 각 인증서를 직접 내보낼 수도 있습니다. 이 기능은 올바른 인증서를 CA 신뢰 목록에 업로드했다고 100% 확신하지 않는 경우에 유용합니다.
이제 Expressway-C가 Expressway-E에서 인증서를 신뢰하므로 반대 방향으로 작동합니다. Expressway-E에 서명한 동일한 CA에서 Expressway-C 인증서를 서명하면 프로세스가 간단합니다. Expressway-E의 Trusted CA 목록에 C에 이미 수행한 것과 동일한 인증서를 업로드하기만 하면 됩니다. C가 다른 CA에 의해 서명된 경우 서명된 Expressway-C 인증서 체인을 대신 사용하는 경우를 제외하고 위와 동일한 프로세스를 따라야 합니다.
Cisco CUCM(Unified Communications Manager)과 Expressway-C 간 보안 통신
개요
Expressway-C와 Expressway-E 간의 접근 영역과 달리 Expressway-C와 CUCM 간에는 보안 신호 처리가 필요하지 않습니다. 내부 보안 정책에서 허용하지 않는 한 이 단계로 이동하기 전에 먼저 CUCM에서 비보안 디바이스 프로파일과 함께 작동하도록 MRA를 구성해야 구축의 나머지가 올바른지 확인할 수 있습니다.
CUCM과 Expressway-C 간에 활성화할 수 있는 두 가지 주요 보안 기능, TLS Verify 및 Secure Device Registrations가 있습니다. 이 두 인증서는 SSL 핸드셰이크의 CUCM과 다른 두 인증서를 사용하기 때문에 중요한 차이점이 있습니다.
TLS 확인 - tomcat 인증서
보안 SIP 등록 - callmanager 인증서
CUCM과 Expressway-C 간의 신뢰 구성
이 경우의 개념은 Expressway-C와 Expressway-E 간의 개념과 정확히 동일합니다. CUCM은 먼저 Expressway-C의 서버 인증서를 신뢰해야 합니다. 즉, CUCM에서 Expressway-C의 중간 인증서와 루트 인증서를 TLS 검증 기능에 대한 tomcat-trust 인증서로 업로드하고 보안 디바이스 등록을 위한 callmanager-trust로 업로드해야 합니다. 이 작업은 CUCM 웹 GUI 오른쪽 상단에서 Cisco Unified OS Administration으로 이동한 다음 Security> Certificate Management를 클릭하여 수행합니다. 여기에서 Upload Certificate/Certificate Chain(인증서/인증서 체인 업로드)을 클릭하고 올바른 신뢰 형식을 선택하거나 Find(찾기)를 클릭하여 현재 업로드된 인증서 목록을 볼 수 있습니다.
또한 Expressway-C가 신뢰할 수 있는 CA 목록에 추가하여 CUCM 인증서를 싱한 CA를 신뢰하는지 확인해야 합니다. 대부분의 경우, CA로 CUCM 인증서에 서명한 경우 tomcat 및 callmanager 인증서는 동일한 CA에서 서명해야 합니다. TLS Verify(TLS 확인) 및 Secure Registrations(보안 등록)를 사용하는 경우 둘 다 신뢰해야 합니다.
보안 SIP 등록을 위해 디바이스에 적용된 CUCM의 보안 디바이스 프로파일 이름이 Expressway-C 인증서에 SAN으로 나열되는지 확인해야 합니다. 보안 레지스터 메시지가 없는 경우 CUCM에서 TLS 오류를 나타내는 "403"과 함께 실패합니다.
자체 서명 인증서를 사용하는 CUCM 서버
기본적으로 CUCM 서버는 자체 서명 인증서와 함께 제공됩니다. 이러한 경우 TLS Verify(확인) 및 Secure Device Registration(보안 디바이스 등록)을 동시에 사용할 수 없습니다. 두 기능 중 하나만 사용할 수 있지만 인증서가 자체 서명되었으므로 자체 서명된 Tomcat 및 자체 서명된 CallManager 인증서를 모두 Expressway-C의 신뢰할 수 있는 CA 목록에 업로드해야 합니다. Expressway-C가 신뢰 목록을 검색하여 인증서를 검증하면 일치하는 주체가 있는 신뢰 목록을 찾으면 중지됩니다. 따라서 신뢰 목록(tomcat 또는 callmanager)의 상위 항목 중 어느 것이든 해당 기능이 작동합니다. 아래는 마치 존재하지 않는 것처럼 실패할 것이다. 이에 대한 해결책은 CA(공용 또는 사설)로 CUCM 인증서에 서명하고 CA만 신뢰하는 것입니다.
Expressway-C 및 Expressway-E 클러스터 고려 사항
클러스터 인증서
이중화를 위해 Expressway-C 또는 Expressway-E 서버 클러스터가 있는 경우 각 서버에 대해 별도의 CSR을 생성하고 CA에서 서명하는 것이 좋습니다. 위의 시나리오에서 각 피어 인증서의 CN(Common Name)은 동일한 클러스터 FQDN(Fully Qualified Domain Name)이 되며 SAN은 클러스터 FQDN과 아래 표시된 각 피어 FQDN이 됩니다.
클러스터 FQDN을 CN으로 사용하고 각 피어 FQDN과 SAN의 클러스터 FQDN을 사용하여 클러스터의 모든 노드에 동일한 인증서를 사용할 수 있으므로 공용 CA에서 서명한 여러 인증서 비용이 발생하지 않습니다.
반드시 필요한 경우 다음 프로세스를 사용하거나 OpenSSL을 사용하여 개인 키와 CSR을 수동으로 생성할 수 있습니다.
1단계. 클러스터의 마스터에서 CSR을 생성하고 클러스터 별칭을 CN으로 나열하도록 구성합니다. 클러스터의 모든 피어를 대체 이름으로 추가하고 다른 모든 필수 SAN도 추가합니다.
2단계. 이 CSR에 서명하고 마스터 피어에 업로드합니다.
3단계. 마스터에 루트로 로그인하고 /tandberg/persistent/certs에 있는 개인 키를 다운로드합니다.
4단계. 서명된 인증서와 일치하는 개인 키를 클러스터의 서로 업로드합니다.
신뢰할 수 있는 CA 목록
클러스터의 CUCM 가입자와 달리 신뢰할 수 있는 CA 목록은 Expressway 또는 VCS 클러스터의 한 피어에서 다른 피어로 복제되지 않습니다. 즉, 클러스터가 있는 경우 각 피어의 CA 목록에 신뢰할 수 있는 인증서를 수동으로 업로드해야 합니다.
다음을 확인합니다.
이 섹션을 사용하여 컨피그레이션이 제대로 작동하는지 확인합니다.
기존 인증서 정보 확인
기존 인증서에 대한 정보를 확인할 수 있는 여러 가지 방법이 있습니다. 첫 번째 옵션은 이전 섹션에서 설명한 방법을 사용하여 웹 브라우저를 통해 제공되며, 이를 사용하여 체인의 특정 인증서를 내보낼 수도 있습니다. Expressway 서버 인증서에 추가된 SAN 또는 기타 특성을 확인해야 하는 경우 Maintenance(유지 관리) > Security Certificates(보안 인증서) > Server Certificate(서버 인증서)로 이동하여 웹 GUI(그래픽 사용자 인터페이스)를 통해 직접 이 작업을 수행할 수 있습니다.
여기에서 다운로드할 필요 없이 인증서의 모든 세부 정보를 볼 수 있습니다. 연결된 서명된 인증서가 아직 업로드되지 않은 경우 활성 CSR에 대해서도 동일한 작업을 수행할 수 있습니다.
Wireshark에서 인증서 읽기/내보내기
인증서 교환 wireshark를 포함한 SSL 핸드셰이크의 Wireshark 캡처가 있는 경우 실제로 인증서를 디코딩하고, 내부에서 전체 체인이 교환된 것으로 가정할 때 체인의 모든 인증서를 실제로 내보낼 수 있습니다. 인증서 교환의 특정 포트에 대한 패킷 캡처를 필터링합니다(일반적으로 통과 영역의 경우 7001). 다음으로, SSL 핸드셰이크와 함께 클라이언트 및 서버 hello 패킷이 표시되지 않으면 TCP 스트림의 패킷 중 하나를 마우스 오른쪽 버튼으로 클릭하고 Decode as Here, select SSL, apply를 클릭합니다. 이제 올바른 트래픽을 캡처했다면 인증서 교환을 확인해야 합니다. 페이로드에서 인증서가 포함된 올바른 서버에서 패킷을 찾습니다. 아래 표시된 인증서 목록이 표시될 때까지 아래쪽 창에서 SSL 섹션을 확장합니다.
여기에서 모든 세부사항을 보기 위해 인증서를 확장할 수 있습니다. 인증서를 내보내려면 체인에서 원하는 인증서를 마우스 오른쪽 버튼으로 클릭하고(여러 개 있는 경우) Export Selected Packet Bytes를 선택합니다. 인증서 이름을 입력하고 저장을 클릭합니다. 이제 Windows 인증서 뷰어에서 인증서를 열거나(.cer 확장명을 제공하는 경우) 분석을 위해 다른 도구에 업로드할 수 있습니다.
문제 해결
이 섹션에서는 컨피그레이션 문제를 해결하는 데 사용할 수 있는 정보를 제공합니다.
Expressway에서 인증서를 신뢰할 수 있는지 테스트
가장 좋은 방법은 인증서 체인을 수동으로 확인하고 모든 구성원이 Expressway 트러스트된 CA 목록에 포함되었는지 확인하는 것이지만, Expressway가 웹 GUI에서 Maintenance(유지 관리) > Security Certificates(보안 인증서)에서 Client Certificate Tested(테스트된 클라이언트 인증서)를 사용하여 특정 클라이언트 인증서를 신뢰하는지 신속하게 확인할 수 있습니다. 모든 기본 설정을 동일하게 유지하고 드롭다운에서 Upload Test File (pem format)(테스트 파일 업로드(pem 형식)를 선택하고 확인할 클라이언트 인증서를 선택합니다. 인증서를 신뢰할 수 없는 경우 아래 오류와 같은 오류가 발생하여 인증서가 거부되었습니다. 오류 아래에는 참조용으로 업로드된 인증서의 디코딩된 정보도 볼 수 있습니다.
Expressway에서 인증서 CRL을 가져올 수 없지만 Expressway에서 CRL 검사를 사용하지 않는다고 주장하는 오류가 발생하는 경우, 이는 인증서를 신뢰할 수 있으며 다른 모든 확인 검사를 통과했음을 의미합니다.
Synergy Light Endpoints(7800/8800 Series Phone)
이러한 새 디바이스에는 잘 알려진 다수의 퍼블릭 CA를 포함하여 미리 채워진 인증서 신뢰 목록이 제공됩니다. 이 신뢰 목록을 수정할 수 없습니다. 즉, 이러한 장치를 사용하려면 일치하는 공용 CA 중 하나에서 Expressway-E 인증서를 서명해야 합니다. 내부 CA 또는 다른 공용 CA에서 서명하면 연결이 실패합니다. 사용자가 Jabber 클라이언트에 있는 대로 인증서를 수동으로 수락하는 옵션은 없습니다.
피드백