피드백을 보내 주셔서 감사합니다.

공개 TLS 인증서 발급에 영향을 미치는 예정된 구글 크롬 브라우저 정책 변경을 알리고 Cisco Webex Calling 전용 인스턴스와 UCM 클라우드 환경에서 상호 TLS (MTL) 연결을 지속적으로 지원하기 위해 시스코가 취할 조치를 설명하기 위한 거예요.

^{2027년 2월 1일부터 구글 크롬 신뢰 프로그램에 포함된 공인 인증 기관 (CA) 이 클라이언트 인증 (ClientAuth) 확장 키 사용 (EKU) 을 포함하는 인증서 서명을 중단해요.}

2027년 3월 15일부터 구글은 크롬 루트 스토어의 퍼블릭 루트 CA가 서버 인증 (^ServerAuth) EKU만 포함하는 인증서를 발급하도록 요구하는 정책을 시행할 거예요. 따라서 Chrome 루트 스토어의 공용 루트 CA는 더 이상 서버 인증과 클라이언트 인증 EKU를 단일 인증서에 결합한 인증서를 발급할 수 없어요.

전용 인스턴스 UC 애플리케이션은 현재 단일 인증서 내에 서버 인증과 클라이언트 인증 EKU를 모두 포함하는 인증서를 사용하여 mTL 연결에 대한 신뢰를 설정해요. 별도의 서버와 클라이언트 인증서에 대한 지원이 이제 UC 애플리케이션 릴리스 V15su5에서 가능해요.

현재 전용 인스턴스는 구글 크롬 루트 스토어의 일부인 IdenTrust 커머셜 루트 CA 1을 사용하여 인증서에 서명해요. 하지만 다가오는 크롬 정책 변경으로 인해 이 CA는 2027년 2월 1일부터 단일 인증서에 두 ^EKU가 모두 포함된 인증서를 더 이상 발급할 수 없어요.

인증서가 영향을 받았어요.

다음 UC 애플리케이션 인증서는 퍼블릭 루트 CA를 사용하여 서명되었으며 일반적으로 mTL 연결에 사용돼요.

UC 애플리케이션	인증서 유형	일반적인 MTL 연결
Cisco Unified CM/SME	톰캣/ 톰캣-ECDSA	LDAP, 파일비트, 로그스태시, MRA를 통한 SIP OAuth, 원격 시스템 로그
	콜 매니저/콜 매니저 - ECDSA	SIP 트렁크, 노드 간 및 클러스터 간 연결
Cisco Unity Connection	톰캣/ 톰캣-ECDSA	SIP 프록시, SIP 트렁크
시스코 IM 앤 프레즌스	톰캣/ 톰캣-ECDSA	—
	컵/ 컵-ECDSA	CUCM, 타사 클라이언트, SIP 프록시를 통한 보안 SIP
	컵-xmpp/Cup-XMP-ECDSA	XMPP 페더레이션
Cisco Emergency Responder	톰캣/ 톰캣-ECDSA	—
Cisco Expressway	서버 인증서	모바일 및 Remote Access (MRA)

인증서는 영향을 받지 않아요.

전용 인스턴스에 남아 있는 모든 인증서는 자체 서명이에요. 추가 정보는 전용 인스턴스 인증서 관리를 참조하세요.

Chrome 정책 변경을 해결하고 중단 없는 mTL 기능을 유지하기 위해 Cisco는 다음 조치를 취할 거예요.

• 2026년 6월 1일부터 ^시스코는 모든 인증서 갱신을 위해 전용 인스턴스 UC 애플리케이션 인증서 서명에 사용되는 퍼블릭 루트 CA를 IdenTrust 상용 루트 CA 1에서 IdenTrust 공공 부문 루트 CA 1로 전환해요.

  인증서 갱신 프로세스는 동일하게 유지되고, Control Hub 경고 센터에서 갱신 일정이 잡히면 “유지 관리 및 중단" 알림을 통해 고객에게 알려 줘요. 자세한 내용은 유지 관리 알림을 참조하세요.

• 인증서에는 서버 및 클라이언트 인증 EKU가 계속 포함될 거예요.

TLS나 mTLS 연결을 사용하여 전용 인스턴스의 UC 애플리케이션을 연결하는 고객 환경의 모든 타사 애플리케이션 또는 서비스는 전용 인스턴스의 UC 애플리케이션과 동일한 인증서 체인을 사용해야 해요. 고객 시스템이나 애플리케이션 신뢰 저장소에 필요한 IdenTrust 인증 기관이 아직 없으면 TLS/mTLS 연결 실패를 방지하려면 새 루트 인증서를 가져와야 해요.

1. 현재 MTL 연결 감사해요
   1. TLS나 mTL을 사용하여 전용 인스턴스의 UC 애플리케이션에 연결하는 애플리케이션, 타사 서비스 또는 통합을 식별하세요.
   2. 해당 애플리케이션이 새 퍼블릭 루트 CA: IdenTrust 공공 부문 루트 CA 1을 신뢰하는지 확인하세요.
2. 새 퍼블릭 루트 CA 추가해요 (필요한 경우)
   1. 고객 애플리케이션이나 시스템 신뢰 저장소에서 IdenTrust 공공 부문 루트 CA 1을 아직 신뢰하지 않으면 추가해야 해요.
   2. 다음 링크에서 같은 걸 다운로드할 수 있어요.

      루트 CA: 아이덴트러스트 공공 부문 루트 CA 1

      대체 다운로드 페이지: IdenTrust 지원 다운로드

      발급/하위 CA: 아이덴트러스트 퍼블릭 섹터 서버 CA 1.

   대부분의 애플리케이션에서 서버가 전체 체인을 제공한다면 루트 CA를 신뢰하는 것으로 충분해요. 발급/하위 CA는 중간 인증서를 별도로 가져와야 하는 애플리케이션에 포함하면 유용해요.

IdenTrust 공공 부문 루트 CA 1은 다음 운영 체제와 플랫폼의 표준 신뢰 저장소에서 기본적으로 신뢰돼요.

• Microsoft Windows
• 맥 오에스
• iOS/ 아이패도스
• Android

따라서 고객은 새 공용 CA의 루트 인증서가 이미 목록에 있는지 확인하기 위해 이러한 플랫폼의 신뢰 저장소를 확인하기만 하면 돼요. 이는 이들 플랫폼의 기본 신뢰 저장소를 사용하는 엔드포인트/클라이언트 또는 타사 시스템에 적용돼요. 각 플랫폼에서 트러스트 스토어를 업데이트하는 방법은 아래 섹션에 나와 있어요. 이러한 업데이트를 수행하는 책임은 고객이나 파트너에게 있습니다. 아래 링크와 단계는 각 플랫폼 공급업체의 온라인 기사를 참조하며 Cisco는 최선을 다해 지원을 제공해요. 더 자세히 설명하려면 각 플랫폼 공급업체와 직접 협력해야 해요.

안드로이드 트러스트 스토어 노트

IdenTrust 퍼블릭 섹터 루트 CA 1은 안드로이드 시스템 CA 스토어에 포함되어 있고 현재 지원되는 안드로이드 버전에서 기본적으로 신뢰돼요. 안드로이드는 개별 루트 인증서 도입 날짜에 대한 버전별 공개 매핑을 제공하지 않아요. 신뢰는 안드로이드 시스템 CA 스토어를 통해 관리되고 운영체제 업데이트와 구글 플레이 시스템 업데이트를 통해 배포돼요.

기기 정책, 엔터프라이즈 관리 제어 또는 애플리케이션별 신뢰 제한으로 Android 시스템 신뢰 저장소를 명시적으로 수정하지 않는 한 고객 조치가 필요하지 않아요.

아이덴트러스트 퍼블릭 섹터 루트 CA 1은 구글 크롬 루트 스토어에 포함되지 않아요.

구글 크롬이 이 루트 CA로 발급한 인증서를 신뢰하도록 하려면 고객은 크롬이 로컬 신뢰 결정을 위해 사용하는 위치의 운영체제 수준에서 루트 인증서를 명시적으로 신뢰하는지 확인해야 해요.

윈도우 — 필수 트러스트 구성

윈도우 구글 크롬에서 루트 CA를 신뢰하도록 하려면 IdenTrust 공공 부문 루트 CA 1을 다음 위치 중 하나로 가져와야 해요.

• 로컬 컴퓨터 → 신뢰할 수 있는 루트 인증 기관

  (엔터프라이즈 매니지드 시스템에 권장)

또는

• 현재 사용자 → 신뢰할 수 있는 루트 인증 기관

  (사용자 수준의 신뢰용)

Windows 인증서 가져오기 마법사를 사용하여 이 위치로 (그룹 정책을 통해) 가져온 인증서는 구글 크롬에서 신뢰해요.

윈도우 서드파티에만 있는 루트 인증서는 위에서 설명한 대로 명시적으로 가져오지 않는 한 크롬에서 자동으로 신뢰하지 않아요.

Mac OS — 필수 트러스트 구성

macOS 구글 크롬에서 루트 CA를 신뢰할 수 있게 하려면 iDenTrust 공공 부문 루트 CA 1을 macOS 키체인에 추가하고 명시적으로 신뢰해야 해요.

1. 시스템 키체인 (권장) 또는 로그인 키체인으로 인증서를 불러와요.

2. 인증서 열고 설정:

   • 이 인증서를 사용할 때는: 항상 믿으세요

     (또는 최소한 SSL: 항상 신뢰)

시스템이나 사용자 수준에서 일단 신뢰되면 구글 크롬은 인증서를 신뢰할 수 있는 것으로 인정해요.

관리자는 크롬: //certificate-manager/localcerts/platformcerts로 이동하여 크롬에서 어떤 플랫폼 인증서를 신뢰하는지 확인할 수 있어요.

자세한 내용은 구글 FAQ를 참조하세요.

타사 통합에는 일차적인 고객 검증이 필요해요.

전용 인스턴스 UC 애플리케이션과 TLS/mTLS 연결을 설정하는 모든 타사 애플리케이션 또는 서비스의 경우 고객은 전용 인스턴스에 영향을 미치는 공개 CA 인증서 변경에 언급된 조치를 따라야 해요.

신뢰 저장소 업데이트가 필요한 경우 타사 공급업체나 IT 관리자와 직접 협업해야 해요. 타사 신뢰 저장소나 인증서 검증 동작을 수정하는 것은 Cisco의 책임 밖의 일이고 Cisco는 타사 인증서 신뢰 구성이나 문제 해결을 지원할 수 없어요.

고객이 IdenTrust 테스트 인증서를 사용하여 새 퍼블릭 루트 CA를 검증할 수 있어요.

페이지가 성공적으로 열리면 님 환경에서 IdenTrust 공공 부문 루트 CA 1을 신뢰할 수 있는 거예요.

이 변경, 구글 크롬 브라우저 정책 또는 전용 인스턴스의 인증서 업데이트와 관련하여 질문이 있으면 컨트롤 허브에서 UC 애플리케이션 라이프사이클의 서비스 요청을 여세요.

자체 도메인을 소유하고 UC 애플리케이션 인증서 갱신을 관리하는 UCM Cloud (UCMC) 고객은, Cisco에 UC 애플리케이션 인증서 서명을 위한 도메인 권한을 위임하지 않은 고객은 선택한 공공 인증 기관에 직접 문의하여 이 변경 사항을 해결해야 해요. 

또한 이러한 고객은 다가오는 공용 CA 및 브라우저 정책 변경과 관련된 인증서 사용 및 교정에 관한 해당 UC 애플리케이션 제품 (Cisco 온프레미스 통화 제품 및 Cisco Expressway) 권장 사항을 준수해야 해요. 자세한 내용은 역할 및 책임을 참조하세요. 

Cisco는 별도의 서버 및 클라이언트 인증서에 대한 UC 애플리케이션 지원이 가능해지면 업데이트를 계속 제공할 거예요. 최신 업데이트는 이 문서를 참조하세요.

인증서 EKU 변경: Cisco 온프레미스 협업 고객이 지금 취해야 할 조치