이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Google Maps Platform 루트 CA 이전 관련 FAQ

이 도움말에는 다음과 같은 섹션이 있습니다.

용어
일반 정보
문제 해결
신뢰할 수 있는 인증서 관리
부록

진행 중인 Google 루트 CA 이전의 자세한 개요는 현재 어떤 상황이 진행되고 있나요?를 참고하세요.

용어

다음은 이 문서의 내용을 이해하기 위해 알고 있어야 하는 주요 용어들입니다. 관련 용어에 대한 보다 포괄적인 내용은 Google Trust Services FAQ를 참고하세요.

SSL/TLS 인증서: 인증서는 ID에 암호화 키를 바인딩합니다.; SSL/TLS 인증서는 웹사이트에 대한 보안 연결을 인증하고 설정하는 데 사용됩니다. 인증서는 인증 기관에서 발급하고 암호로 서명합니다.; 브라우저는 신뢰할 수 있는 인증 기관에서 발급한 인증서를 사용해 전송된 정보가 올바른 서버에 암호화되어 전송되는지 확인합니다.
보안 소켓 레이어(SSL): 보안 소켓 레이어는 인터넷 통신을 암호화하는 데 사용되는 가장 광범위하게 배포된 프로토콜이었습니다. SSL 프로토콜은 더 이상 안전하지 않으므로 사용해서는 안 됩니다.
전송 계층 보안(TLS): 전송 계층 보안은 SSL의 후속 프로토콜입니다.
인증 기관(CA): 인증 기관은 기기와 사용자를 위한 디지털 여권 발급 사무소와 같습니다. 인증 기관에서는 암호로 보호되는 문서(인증서)를 발급하여 인증 대상(예: 웹사이트)의 신원을 증명합니다.; 인증서를 발급하기 전에 CA는 인증서의 이름이 인증서를 요청한 사람이나 기관에 연결되어 있는지 확인해야 합니다.; 인증 기관이라는 용어는 Google Trust Services와 같은 조직과 인증서를 발급하는 시스템 모두를 의미할 수 있습니다.
루트 인증서 저장소: 루트 인증서 저장소에는 애플리케이션 소프트웨어 공급업체가 신뢰하는 인증 기관의 집합이 포함됩니다. 대부분의 웹브라우저와 운영체제에는 자체 루트 인증서 저장소가 있습니다.; 애플리케이션 소프트웨어 공급업체가 명시한 엄격한 요구사항을 준수하는 인증 기관만 루트 인증서 저장소에 포함됩니다.; 해당 요구사항은 보통 CA/브라우저 포럼 관련 요구사항과 같은 업계 표준 준수를 포함합니다.
루트 인증 기관: 루트 인증 기관(더 정확하게는 기관에서 발급된 인증서)은 인증서 체인의 가장 상위에 있는 인증서입니다.; 루트 CA 인증서는 일반적으로 자체 서명됩니다. 루트 CA 인증서와 연결된 비공개 키는 매우 안전한 시설에 보관되고 무단 액세스로부터 보호하기 위해 오프라인 상태에서 유지관리됩니다.
중간 인증 기관: 중간 인증 기관(더 정확하게는 기관에서 발급된 인증서)은 인증서 체인에서 다른 인증서에 서명하는 데 사용되는 인증서입니다.; 중간 CA는 루트 CA 인증서를 오프라인으로 유지하면서 온라인 인증서를 발급하기 위한 기관입니다.; 중간 CA는 하위 CA라고도 합니다.
발급 인증 기관: 발급 인증 기관(더 정확하게는 기관에서 발급된 인증서)은 인증서 체인에서 가장 하위에 있는 인증서에 서명하는 데 사용되는 인증서입니다.; 가장 하위에 있는 이 인증서는 일반적으로 구독자 인증서, 종단 개체 인증서 또는 리프 인증서라고 합니다. 이 문서에서는 서버 인증서라는 용어도 사용됩니다.
인증서 체인: 인증서는 발급기관에 연결되고 발급기관에 의해 암호로 서명됩니다. 인증서 체인은 리프 인증서, 모든 발급기관 인증서, 루트 인증서로 구성됩니다.
교차 서명: 애플리케이션 소프트웨어 공급업체의 클라이언트는 제품에서 새 CA 인증서를 신뢰할 수 있도록 새 CA 인증서를 포함하기 위해 루트 인증서 저장소를 업데이트해야 합니다. 새 CA 인증서가 포함된 제품이 광범위하게 사용될 때까지 시간이 조금 걸립니다.; 이전 클라이언트와의 호환성을 높이기 위해 이전에 설정된 다른 CA에서 CA 인증서를 '교차 서명'할 수 있습니다. 이렇게 하면 동일한 ID(이름 및 키 쌍)에 대한 두 번째 CA 인증서가 실질적으로 생성됩니다.; 루트 인증서 저장소에 포함된 CA에 따라 클라이언트는 신뢰할 수 있는 루트까지 다른 인증서 체인을 빌드합니다.

일반 정보

현재 어떤 상황이 진행되고 있나요?

개요

2017년, Google은 HTTPS에서 사용하는 TLS 인터넷 보안의 기본이 되는 암호화 서명인 루트 인증서를 발급하고 사용하기 위한 프로젝트를 시작하여 여러 해에 걸쳐 진행하고 있습니다.

프로젝트 1단계 완료 후, Google Maps Platform 서비스의 TLS 보안은 신뢰할 수 있고 높은 인지도를 자랑하는 루트 인증 기관(CA)인 GS Root R2의 보장을 받았습니다. GS Root R2는 Google이 자체 발급하는 Google Trust Services(GTS) 루트 CA로 원활하게 전환하기 위해 GMO GlobalSign으로부터 인수했습니다.

실제로 모든 TLS 클라이언트(예: 웹브라우저, 스마트폰, 애플리케이션 서버)가 이 루트 인증서를 신뢰하여 첫 번째 이전 단계에서 Google Maps Platform 서버와 보안 연결을 설정할 수 있었습니다.

하지만 CA는 설계상 자체 인증서의 만료 시간 이후에 유효한 인증서를 발급할 수 없습니다. GS Root R2가 2021년 12월 15일에 만료됨에 따라 Google은 Google의 자체 루트 CA인 GTS Root R1에서 발급한 인증서를 사용하여 서비스를 새로운 CA인 GTS Root R1 Cross로 이전할 예정입니다.

오늘날 사용 중인 대다수의 운영체제와 TLS 클라이언트 라이브러리는 이미 GTS 루트 CA를 신뢰하지만, 대부분의 기존 시스템에서 전환이 원활하게 이루어지도록 Google은 현재 이용 가능한 루트 CA 중 가장 오래되고 가장 신뢰할 수 있는 GlobalSign Root CA - R1을 사용하여 GMO GlobalSign의 교차 서명을 받았습니다.

따라서 고객 대부분 Google Maps Platform 클라이언트는 신뢰도가 높은 해당 루트 CA 중 하나(또는 둘 모두)를 이미 인정하며 두 번째 이전 단계에 전혀 영향을 받지 않습니다.

2018년 첫 번째 이전 단계에서 조치를 취하고 Google 안내에 따라 신뢰할 수 있는 Google 루트 CA 번들에서 모든 인증서를 설치한 고객의 경우에도 마찬가지입니다.

다음과 같은 경우 시스템을 확인해야 합니다.

서비스가 비표준 플랫폼 또는 기존 플랫폼에서 실행되거나 자체 루트 인증서 저장소를 유지관리하는 경우
2017~2018년에 Google 루트 CA의 첫 번째 이전 단계에서 조치를 취하지 않았거나 신뢰할 수 있는 Google 루트 CA 번들에서 모든 인증서를 설치하지 않은 경우

위의 경우 이 이전 단계에서 Google Maps Platform을 끊김 없이 사용하려면 클라이언트를 추천 루트 인증서로 업데이트해야 할 수도 있습니다.

자세한 기술 세부정보는 아래를 참고하세요. 일반적인 안내는 루트 인증서 저장소에 업데이트가 필요한지 확인하는 방법 섹션을 참고하세요.

또한 서비스가 향후 루트 CA 변경에 영향을 받지 않도록 루트 인증서 저장소를 위의 선별된 루트 CA 번들과 계속 동기화하는 것이 좋습니다. 하지만 변경사항은 사전에 발표됩니다. 최신 정보를 확인하는 방법에 관한 자세한 내용은 이 이전 단계에 관한 업데이트를 받으려면 어떻게 해야 하나요?와 향후 이전에 관한 사전 알림을 받으려면 어떻게 해야 하나요? 섹션을 참고하세요.

기술 요약

2021년 3월 15일 Google 보안 블로그에 발표된 바와 같이, 2018년 초부터 Google Maps Platform에서 사용한 루트 CA인 GS Root R2는 2021년 12월 15일에 만료됩니다. 따라서 Google은 올해 안에 새로 발급된 CA GTS Root R1 Cross로 이전할 예정입니다. 즉 Google 서비스는 이 새로운 CA에서 발급된 TLS 리프 인증서로 점차적으로 전환될 예정입니다.

거의 모든 최신 TLS 클라이언트와 시스템이 이미 GTS Root R1 인증서로 사전 구성되어 있거나 일반 소프트웨어 업데이트를 통해 인증서를 받고 있으며, GlobalSign Root CA - R1은 기존 시스템에서도 사용할 수 있습니다.

그러나 다음 두 경우에 모두 해당하면 적어도 시스템을 확인해야 합니다.

서비스가 비표준 플랫폼 또는 기존 플랫폼에서 실행되거나 자체 루트 인증서 저장소를 유지관리하는 경우
2017~2018년에 Google 루트 CA의 첫 번째 이전 단계에서 조치를 취하지 않거나 신뢰할 수 있는 Google 루트 CA 번들에서 모든 인증서를 설치하지 않은 경우

루트 인증서 저장소에 업데이트가 필요한지 확인하는 방법 섹션에 시스템이 영향을 받는지 테스트하는 일반적인 방법이 설명되어 있습니다.

자세한 내용은 루트 인증서 저장소를 신뢰할 수 있는 Google 루트 CA 번들과 동기화해야 하는 이유는 무엇인가요?를 참고하세요.

이 이전 단계에 관한 업데이트를 받으려면 어떻게 해야 하나요?

업데이트를 받으려면 공개 문제 186840968에 별표를 표시하세요. 이 FAQ는 이전 과정 전반에 걸쳐 일반적으로 관심을 끄는 주제가 발견될 때마다 업데이트됩니다.

향후 이전에 관한 사전 알림을 받으려면 어떻게 해야 하나요?

Google 보안 블로그를 따르시기 바랍니다. Google은 또한 블로그에 공개적으로 발표한 후 최대한 빨리 제품별 문서를 업데이트하기 위해 노력합니다.

또한 Google에서는 수많은 고객에게 영향을 줄 수 있는 변경사항에 관한 업데이트를 포럼에 정기적으로 게시하고 있으므로, Google Maps Platform 알림을 구독하시기 바랍니다.

여러 Google 서비스를 사용합니다. 루트 CA 이전이 모든 서비스에 영향을 미치나요?

예. 루트 CA 이전은 모든 Google 서비스와 API에서 발생하지만 타임라인은 서비스별로 다를 수 있습니다. 하지만 Google Maps Platform 클라이언트 애플리케이션에서 사용하는 루트 인증서 저장소에 신뢰할 수 있는 Google 루트 CA 번들에 등록된 모든 서비스가 포함되어 있는 경우에는 서비스가 진행 중인 이전에 받지 않으며 루트 인증서 저장소와 신뢰할 수 있는 Google 루트 CA 번들을 동기화하면 향후 루트 CA 변경에도 영향을 받지 않습니다.

자세한 내용은 루트 인증서 저장소를 신뢰할 수 있는 Google 루트 CA 번들과 동기화해야 하는 이유는 무엇인가요? 및 손상될 위험이 있는 애플리케이션에는 어떤 것이 있나요?를 참고하세요.

아래의 루트 인증서 저장소에 업데이트가 필요한지 확인하는 방법 섹션에서는 시스템 테스트에 관한 일반적인 안내도 제공합니다.

루트 인증서 저장소에 업데이트가 필요한지 확인하는 방법

아래의 테스트 엔드포인트에 대해 애플리케이션 환경을 테스트하세요.

GTS Root R1 Cross 테스트 엔드포인트에 TLS 연결을 설정할 수 있으면 GS Root R2 만료의 영향을 받지 않습니다.
GTS Root R1 테스트 엔드포인트에 TLS 연결을 설정할 수 있으면 2028년에 GTS Root R1 Cross 및 GlobalSign Root CA - R1이 만료되어도 영향을 받지 않을 수 있습니다.

일반적으로 다음과 같은 경우에 루트 CA 변경사항이 시스템에 문제없이 적용됩니다.

서비스가 유지관리되는 일반 운영체제에서 실행되며, 서비스에서 사용하는 운영체제와 라이브러리에 모두 지속적으로 패치를 설치했으며 자체 루트 인증서 저장소를 유지하고 있지 않은 경우 또는
Google의 이전 권장사항에 따라 신뢰할 수 있는 Google 루트 CA 번들의 모든 루트 CA를 설치한 경우

영향을 받을 가능성이 있는 고객은 서비스가 중단되지 않도록 즉시 신뢰할 수 있는 Google 루트 CA 번들에서 인증서를 설치해야 합니다.

자세한 내용은 루트 인증서 저장소를 신뢰할 수 있는 Google 루트 CA 번들과 동기화해야 하는 이유는 무엇인가요?를 참고하세요.

루트 인증서 저장소를 확인하는 데 사용할 수 있는 간단한 도구가 있나요?

두 가지 명령줄 도구 curl 및 openssl이 조사에 유용합니다. 둘 다 대부분의 플랫폼에서 사용할 수 있으며 광범위한 설정 테스트 옵션을 제공합니다.

curl을 가져오는 방법은 아래의 curl 가져오기 섹션을 참고하세요.

아래의 openssl 명령어는 버전 1.1.1 이상용입니다. 1.1.1보다 낮은 버전은 지원되지 않습니다. 이전 버전을 사용하는 경우 버전에 맞게 이러한 명령어를 업그레이드하거나 수정하세요. openssl을 가져오는 방법은 아래 OpenSSL 가져오기 섹션을 참고하세요.

아래의 필요한 도구는 어디에서 얻을 수 있나요? 섹션에도 유용한 도구가 나와 있습니다.

구체적인 테스트 안내는 루트 인증서 저장소에 업데이트가 필요한지 확인하는 방법 섹션을 참고하세요.

기본 루트 인증서 저장소 테스트

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

신뢰할 수 있는 Google 루트 CA 번들 확인

신뢰할 수 있는 Google 루트 CA 번들을 다운로드하고 다음 단계를 따릅니다.

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Google 루트 CA 이전은 언제 어떻게 계속되나요?

2017년 1월에 발표된 1단계(GS Root R2로의 이전)는 2017년 말에 시작되어 2018년 상반기에 완료되었습니다.
2단계(GTS Root R1 Cross로의 이전)는 2021년 3월에 발표되었으며 앞으로 몇 달 동안 2021년 12월 15일 GS Root R2가 만료되기 전에 진행될 예정입니다.

이후 최종 이전 단계의 일정은 향후 인증서가 만료되기 한참 전에 발표될 예정입니다.

하지만 루트 인증서 저장소를 신뢰할 수 있는 Google 루트 CA 번들의 선별된 루트 CA 목록과 동기화된 상태로 유지하면 앞으로도 계속 앱을 사용할 수 있습니다.

자세한 내용은 루트 인증서 저장소를 신뢰할 수 있는 Google 루트 CA 번들과 동기화해야 하는 이유는 무엇인가요?에서도 참고할 수 있습니다.

각 Google 서비스의 일반 출시 계획

단계적 출시는 단일 데이터 센터에서 시작됩니다.
전세계에 서비스할 수 있도록 점진적으로 더 많은 데이터 센터에 출시될 예정입니다.
임의의 단계에서 심각한 문제가 감지되면 문제가 해결되는 동안 테스트가 일시적으로 롤백될 수 있습니다.
이전의 반복된 입력을 기반으로 모든 Google 서비스가 점진적으로 새 인증서로 이전될 때까지 추가 Google 서비스가 출시에 포함됩니다.

누가 언제 어디서 영향을 받나요?

Google Maps Platform의 수를 늘리면 새 데이터 센터로 이전함에 따라 개발자가 새 인증서를 받기 시작합니다. 클라이언트 요청이 지리적으로 인접한 데이터 센터의 서버로 전달되는 경향이 있기 때문에 변경사항은 어느 정도 현지화됩니다.

누가 언제 어디서 영향을 받을지 미리 확실하게 알 수 없으므로 모든 고객은 가능한 Google 루트 CA 이전 단계 전에 앞으로도 계속해서 서비스를 사용할 수 있는지 미리 확인하는 것이 좋습니다.

자세한 내용은 루트 인증서 저장소에 업데이트가 필요한지 확인하는 방법 섹션을 참고하세요.

주의사항

필요한 루트 인증서로 구성되지 않은 클라이언트는 Google Maps Platform에 대한 TLS 연결을 확인할 수 없습니다. 이 경우 클라이언트는 일반적으로 인증서 유효성 검사에 실패했다는 경고를 표시합니다.

TLS 구성에 따라 클라이언트가 Google Maps Platform 요청을 계속 발행하거나 요청 진행을 거부할 수도 있습니다.

TLS 클라이언트가 Google Maps Platform과 통신하기 위한 최소 요구사항은 무엇인가요?

Google Maps Platform 인증서는 DNS 주체 대체 이름(SAN)을 사용하므로 클라이언트의 인증서에서 단일 와일드 카드가 가장 왼쪽 라벨로 포함된 SAN을 처리할 수 있어야 합니다(예: *.googleapis.com).

기타 요구사항은 GTS FAQ의 TLS 클라이언트가 Google과 통신하기 위한 최소 요구사항은 무엇인가요? 섹션을 참고하세요.

어떤 종류의 애플리케이션이 손상될 위험이 있나요?

애플리케이션이 개발자가 설정한 제한사항 없이 시스템 루트 인증서 저장소를 사용함

Google Maps Platform 웹 서비스 애플리케이션

아직 유지관리되고 정기적으로 업데이트를 받는 주요 OS(예: Ubuntu, Red Hat, Windows 10 또는 Server 2019, OS X)를 사용하는 경우 기본 루트 인증서 저장소에 항상 GTS Root R1 인증서가 포함됩니다.

더 이상 업데이트를 받지 않는 기존 OS 버전을 사용하는 경우 GTS Root R1 인증서가 있을 수도 있고 없을 수도 있습니다. 하지만 루트 인증서 저장소에는 가장 오래되고 가장 광범위하게 신뢰되는 루트 CA 중 하나인 GlobalSign Root CA - R1이 포함될 가능성이 큽니다.

최종 사용자 기기에서 직접 Google Maps Platform 웹 서비스를 호출하는 모바일 애플리케이션의 경우 모바일 앱이 손상될 위험이 있나요?의 가이드라인이 적용됩니다.

클라이언트 측 Google Maps Platform 애플리케이션

Maps JavaScript API 애플리케이션에서는 일반적으로 애플리케이션을 실행하는 웹브라우저의 루트 인증서를 사용합니다. 자세한 내용은 JavaScript 애플리케이션이 손상될 위험이 있나요? 섹션을 참고하세요.

Android용 Maps SDK, iOS용 Maps SDK, Android용 Places SDK 또는 iOS용 Places SDK를 사용하는 기본 모바일 애플리케이션의 경우 Google Maps Platform 웹 서비스를 호출하는 앱과 동일한 규칙이 적용됩니다.

자세한 내용은 모바일 앱이 손상될 위험이 있나요?를 참고하세요.

앱이 자체 인증서 번들을 사용하거나 인증서 고정과 같은 고급 보안 기능을 사용함

인증서 번들을 직접 업데이트해야 합니다. 루트 인증서 저장소를 신뢰할 수 있는 Google 루트 CA 번들과 동기화해야 하는 이유는 무엇인가요?에 설명된 대로 신뢰할 수 있는 Google 루트 CA 번들의 모든 인증서를 자체 루트 인증서 저장소로 가져오는 것이 좋습니다.

애플리케이션이 연결되는 Google 도메인의 인증서 또는 공개 키를 고정하는 경우 애플리케이션의 신뢰할 수 있는 인증 대상 목록에 인증서와 공개 키를 추가해야 합니다.

인증서 또는 공개 키 고정에 대한 자세한 내용은 추가 정보가 필요하신가요?에 표시된 외부 리소스를 참고하세요.

루트 인증서 저장소를 신뢰할 수 있는 Google 루트 CA 번들과 동기화해야 하는 이유는 무엇인가요?

신뢰할 수 있는 Google 루트 CA 번들의 선별된 루트 CA 목록에는 가까운 미래에 Google 서비스에서 사용될 가능성이 있는 모든 CA가 포함됩니다.

따라서 미래에도 시스템을 사용할 수 있도록 설정하려면 루트 인증서 저장소에 번들의 모든 인증서가 포함되어 있는지 확인하고, 신뢰할 수 있는 번들과 루트 인증서 저장소를 습관적으로 동기화하는 것이 좋습니다.

서비스가 유지관리되지 않은 운영체제 버전에서 실행되거나, 다른 이유로 운영체제 및 라이브러리를 패치할 수 없거나 자체 루트 인증서 저장소를 유지관리하는 경우 특히 이렇게 하는 것이 중요합니다.

향후 루트 CA 이전에 관한 업데이트를 받는 방법은 향후 이전에 관한 사전 알림을 받으려면 어떻게 해야 하나요?를 참고하세요. 루트 인증서 저장소를 선별된 목록과 정기적으로 동기화하면 향후 CA 변경으로 인한 중단으로부터 서비스가 보호되며 GTS Root R1 Cross와 GlobalSign Root CA - R1이 모두 만료된 후에도 서비스를 계속 실행할 수 있습니다.

Google 서비스에 연결되는 제품을 빌드하고 있습니다. 어떤 CA 인증서를 신뢰해야 하나요?(GTS FAQ)의 내용도 참고하세요.

리프 인증서 또는 중간 CA 인증서를 설치해서는 안 되는 이유는 무엇인가요?

이렇게 하면 Google에서 새 인증서를 등록하거나 중간 CA를 전환할 때 애플리케이션이 손상될 위험이 있습니다. Google은 언제든지 사전 고지 없이 새 중간 인증서를 등록하거나 중간 CA를 전환할 수 있으며, 개별 서버 인증서(예: maps.googleapis.com에서 제공하는 인증서)는 물론 중간 CA(예: GTS Root R1 Cross)의 경우에도 마찬가지입니다.

이러한 위험으로부터 서비스를 보호하려면 신뢰할 수 있는 Google 루트 CA 번들의 루트 인증서만 설치하고 루트 인증서만 사용하여 루트 인증서에 고정된 전체 서버 인증서 체인의 신뢰도를 확인해야 합니다.

루트 인증 기관을 신뢰할 수 있는 경우 모든 최신 TLS 라이브러리 구현에서 신뢰할 수 있는 이 인증서 체인을 자동으로 확인할 수 있어야 합니다.

JavaScript 애플리케이션이 손상될 위험이 있나요?

GTS 루트 인증서는 이미 잘 삽입되어 있고 대부분의 최신 브라우저에서 신뢰하며, GMO GlobalSign의 교차 서명 덕분에 기존 브라우저의 최종 사용자도 대부분 원활한 이전이 가능할 것입니다. 여기에는 Maps JavaScript API가 공식적으로 지원되는 모든 브라우저가 포함됩니다.

모든 최신 브라우저에서 최종 사용자가 브라우저에서 신뢰하는 인증서를 확인하고 일반적으로 수정할 수 있습니다. 정확한 위치는 브라우저마다 다르지만 일반적으로 설정 아래에 인증서 목록이 있습니다.

모바일 앱이 손상될 위험이 있나요?

기기 제조업체로부터 여전히 정기적으로 업데이트를 받는 Android 및 Apple iOS 기기는 앞으로도 계속해서 사용할 수 있을 것으로 예상됩니다. 대부분의 이전 Android 휴대전화 모델에는 최소한 GlobalSign Root CA - R1 인증서가 포함되어 있지만 신뢰할 수 있는 인증서 목록은 핸드셋 제조업체, 기기 모델, Android 버전마다 다를 수도 있습니다.

하지만 Android 10 이전 버전에서는 GTS Root R1을 포함하여 GTS 루트 CA 지원이 여전히 제한될 수도 있습니다.

iOS 기기의 경우 Apple이 지원 페이지에 각 iOS 버전에 대해 신뢰할 수 있는 루트 CA의 목록을 유지합니다. 하지만 iOS 5 이상의 모든 버전은 GlobalSign Root CA - R1을 지원합니다.

GTS Root R1을 포함한 GTS 루트 CA는 iOS 12.1.3 버전부터 지원되었습니다.

자세한 내용은 휴대전화에서 신뢰할 수 있는 루트 인증서를 확인하려면 어떻게 해야 하나요?를 참고하세요.

Google Trust Services 루트 인증서가 언제 브라우저 또는 운영체제에 포함되나요?

Google은 지난 몇 년 동안 주요 외부 업체와 광범위하게 협력하면서 폭넓게 사용되는 신뢰할 수 있는 루트 인증서 번들을 유지관리해 왔습니다. 운영체제 제조업체(Apple, Microsoft 등)를 비롯하여 Google 자체 Android 및 ChromeOS팀, 브라우저 개발업체(Mozilla, Apple, Microsoft), Google 자체 Chrome팀, 하드웨어 제조업체(휴대전화, 셋톱 박스, TV, 게임 콘솔, 프린터 등)가 대표적인 예입니다.

따라서 현재 유지관리되는 시스템이 GTS Root R1을 비롯한 Google의 새 GTS 루트 CA를 이미 지원하고 있을 가능성이 매우 크고 기존 시스템도 향후 몇 년간 Google에서 발급하는 인증서의 교차 서명에 사용될 GlobalSign Root CA - R1을 지원할 가능성이 큽니다.

하지만 서드 파티 인증서 포함 타임라인은 대체로 Google에서 관리할 수 없으므로 가장 좋은 방법은 사용 가능한 시스템 업데이트를 정기적으로 실행하는 것입니다.

Mozilla의 CA 인증서 프로그램과 같은 일부 서드 파티 프로그램의 경우 자체 인증서 포함 타임라인을 문서화했을 수도 있습니다.

문제 해결

필요한 도구는 어디에서 얻을 수 있나요?

curl 가져오기

OS 배포판에서 curl을 제공하지 않으면 https://curl.haxx.se/에서 다운로드할 수 있습니다. 소스를 다운로드하여 도구를 직접 컴파일하거나 사전 컴파일된 바이너리를 다운로드할 수 있습니다(플랫폼에 사용 가능한 바이너리가 있는 경우).

OpenSSL 가져오기

OS 배포판에서 openssl을 제공하지 않으면 https://www.openssl.org/에서 소스를 다운로드하여 도구를 컴파일할 수 있습니다. 타사에서 빌드한 바이너리 목록은 https://www.openssl.org/community/binaries.html을 통해 확인할 수 있습니다. 하지만 이러한 빌드는 모두 OpenSSL팀에서 지원하거나 특정한 방식으로 보증하지 않습니다.

Wireshark, Tshark 또는 Tcpdump 가져오기

대부분의 Linux 배포판은 wireshark, 명령줄 도구 tshark 및 tcpdump를 모두 제공하며 처음 두 도구의 사전 컴파일된 다른 OS용 버전은 https://www.wireshark.org에서 찾을 수 있습니다.

Tcpdump 및 LibPCAP의 소스 코드는 https://www.tcpdump.org에서 찾을 수 있습니다.

이 유용한 도구에 관한 문서는 Tshark 설명서 페이지 및 Tcpdump 설명서 페이지의 Wireshark 사용자 가이드에서 찾을 수 있습니다.

Java Keytool 가져오기

keytool 명령줄 도구는 모든 Java 개발 키트(JDK) 또는 Java 런타임 환경(JRE) 버전과 함께 제공됩니다. keytool.을 가져오려면 이 버전을 설치하세요. 하지만 Java를 사용하여 애플리케이션을 빌드하지 않는 한 keytool을 사용하여 루트 인증서를 확인할 필요는 없습니다.

프로덕션이 중단되면 어떻게 해야 하나요?

먼저 취해야 할 조치는 신뢰할 수 있는 Google 루트 CA 번들의 필수 루트 인증서를 애플리케이션에서 사용하는 루트 인증서 저장소에 설치하는 것입니다.

시스템 관리자와 협력하여 로컬 루트 인증서 저장소를 업그레이드합니다.
이 FAQ에 사용 중인 시스템에 해당하는 포인터가 있는지 확인합니다.
플랫폼 또는 시스템별 지원이 더 필요한 경우 시스템 공급자가 제공하는 기술 지원 채널에 문의합니다.
일반 지원의 경우 Google Maps Platform 지원팀에 문의하기 섹션에 설명된 대로 지원팀에 문의합니다. 참고: 플랫폼별 문제의 경우 최선을 다해 지원해 드립니다.
이전 관련 추가 업데이트를 받으려면 공개 문제 186840968에 별표를 표시하세요.

Google Maps Platform 지원팀에 문의하기

초기 문제 해결

일반적인 문제 해결 방법은 루트 인증서 저장소에 업데이트가 필요한지 확인하는 방법 섹션을 참고하세요.

루트 인증서를 가져오거나 내보내야 하는 경우 신뢰할 수 있는 인증서 관리 섹션도 참고하세요.

문제가 해결되지 않아 Google Maps Platform 지원팀에 문의하는 경우 다음 정보도 제공해야 합니다.

영향을 받은 서버의 위치
서비스에서 호출하는 Google IP 주소
이 문제의 영향을 받는 API
문제가 시작된 정확한 시간

다음 명령어의 출력:

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

필요한 도구는 어디에서 찾을 수 있나요?에서 필요한 도구를 얻는 방법을 참고하세요.

지원 케이스 제출

Google Maps Platform 지원 및 리소스의 지원 케이스 만들기 안내를 따르세요.

지원 케이스를 제출할 때는 초기 문제 해결 섹션에 표시된 데이터 외에 다음 항목도 제공하세요.

공개 IP 주소
DNS 서버의 공개 IP 주소
가능한 경우 https://maps.googleapis.com/에 대해 실패한 TLS 협상의 tcpdump 또는 Wireshark 패킷 캡처(전체 패킷을 자르지 않고 캡처하기에 충분히 큰 스냅샷 길이를 사용하는 PCAP 형식)(예: tcpdump 버전에서 -s0 사용)
가능한 경우 정확한 TLS 서버 실패 이유를 보여주는 서비스의 로그 발췌 부분(가급적이면 전체 서버 인증서 체인 정보가 포함된 부분)

필요한 도구는 어디에서 찾을 수 있나요?에서 필요한 도구를 얻는 방법을 참고하세요.

공개 문제 186840968에 게시

공개 문제 186840968에 댓글을 게시할 때는 초기 문제 해결 섹션에 표시된 정보를 포함하세요.

DNS의 공개 주소를 확인하려면 어떻게 해야 하나요?

Linux에서는 다음 명령어를 실행할 수 있습니다.

dig -t txt o-o.myaddr.l.google.com

Windows의 경우 대화형 모드에서 nslookup을 사용할 수 있습니다.

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

curl 출력을 해석하는 방법

-vvI 플래그를 사용하여 curl을 실행하면 훨씬 유용한 정보를 얻을 수 있습니다. 출력을 해석하는 방법은 다음과 같습니다.

'*'로 시작하는 행에는 TLS 협상의 출력 및 연결 종료 정보가 표시됩니다.
'>'로 시작하는 행에는 curl에서 전송하는 발신 HTTP 요청이 표시됩니다.
'<'로 시작하는 행에는 서버에서 받는 HTTP 응답이 표시됩니다.
프로토콜이 HTTPS인 경우 '>' 또는 '<' 행이 있으면 TLS 핸드셰이크가 성공한 것입니다.

사용된 TLS 라이브러리 및 루트 인증서 번들

-vvI 플래그를 사용하여 curl을 실행하면 사용된 루트 인증서 저장소가 출력되지만 정확한 출력은 여기 표시된 것과 같이 시스템마다 다를 수 있습니다.

NSS에 연결된 curl이 있는 Red Hat Linux 시스템의 출력에는 다음 행이 포함될 수 있습니다.

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

Ubuntu 또는 Debian Linux 시스템의 출력에는 다음 행이 포함될 수 있습니다.

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

--cacert 플래그를 사용하여 지정된 Google 루트 인증서 PEM 파일을 사용하는 Ubuntu 또는 Debian Linux 시스템의 출력에는 다음 행이 포함될 수 있습니다.

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

사용자 에이전트

발신 요청에는 curl 및 시스템에 대한 유용한 정보를 제공하는 User-Agent 머리글이 포함됩니다.

Red Hat Linux 시스템의 예:

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

TLS 핸드셰이크 실패

이 코드 샘플과 같은 행은 신뢰할 수 없는 서버 인증서로 인해 TLS 핸드셰이크 중에 연결이 종료되었음을 나타냅니다. > 또는 <로 시작하는 디버그 출력이 없어도 연결 시도 실패를 나타냅니다.

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

TLS 핸드셰이크 성공

이 코드 샘플과 비슷한 행은 TLS 핸드셰이크 성공을 나타냅니다. 암호화된 연결에 사용된 암호화 스위트가 표시되고 수락된 서버 인증서의 세부정보도 표시됩니다. 또한 > 또는 <로 시작하는 행이 있으면 페이로드 HTTP 트래픽이 TLS 암호화 연결을 통해 성공적으로 전송되고 있음을 나타냅니다.

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

수신된 서버 인증서를 사람이 읽을 수 있는 형태로 인쇄하는 방법

출력이 PEM 형식이라고 가정하면(예: openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null의 출력) 다음 단계에 따라 제공된 인증서를 인쇄할 수 있습니다.

머리글과 바닥글을 포함하여 Base64로 인코딩된 인증서 전체를 복사합니다.
```
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
```

그런 다음 아래 작업을 실행합니다.

openssl x509 -inform pem -noout -text
````

그런 다음 복사 버퍼의 내용을 터미널에 붙여넣습니다.
Return 키를 누릅니다.

입력 및 출력 예는 아래 PEM 인증서를 사람이 읽을 수 있는 형태로 인쇄하는 방법 섹션을 참고하세요.

OpenSSL의 교차 서명된 Google 인증서는 어떤 형식인가요?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

신뢰할 수 있는 인증서 관리

휴대전화에서 신뢰할 수 있는 루트 인증서를 확인하려면 어떻게 해야 하나요?

Android 신뢰할 수 있는 인증서

모바일 앱이 손상될 위험이 있나요?에 설명된 대로 Android 버전 4.0부터는 핸드셋 사용자가 설정에서 신뢰할 수 있는 인증서 목록을 확인할 수 있습니다. 다음 표는 정확한 설정 메뉴 경로를 보여줍니다.

Android 버전	메뉴 경로
1.x, 2.x, 3.x	해당 사항 없음
4.x, 5.x, 6.x, 7.x	설정 > 보안 > 신뢰할 수 있는 사용자 인증 정보
8.x, 9	설정 > 보안 및 위치 > 암호화 및 사용자 인증 정보 > 신뢰할 수 있는 사용자 인증 정보
10 이상	설정 > 보안 > 고급 > 암호화 및 사용자 인증 정보 > 신뢰할 수 있는 사용자 인증 정보

다음 표에는 현재 사용할 수 있는 Android Virtual Device(AVD) 시스템 이미지를 사용하는 수동 인증을 기반으로 Android 버전별로 가장 중요한 루트 인증서의 예상 이용 가능 여부가 표시되며 시스템 이미지를 더 이상 사용할 수 없는 경우 AOSP ca-certificates Git 저장소 버전 기록으로 돌아갑니다.

Android 버전	GTS Root R1	GlobalSign Root CA - R1	GlobalSign Root R2(2021년 12월 15일까지 유효)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10 이상

일반적으로는 펌웨어를 업데이트하거나 기기를 루팅하지 않고 Android 시스템 루트 인증서 저장소를 업데이트할 수 없습니다. 하지만 여전히 널리 사용되는 대부분의 Android 버전에서 현재 신뢰할 수 있는 루트 인증서 세트는 대부분의 현재 기존 기기의 전체 유효 기간을 넘어 향후 수년간 서비스를 끊김 없이 제공할 가능성이 큽니다.

버전 7.0부터 Android는 애플리케이션 개발자에게 애플리케이션에서만 신뢰할 수 있는 인증서를 추가하는 안전한 방법을 제공합니다. Android 보안 및 개인 정보 보호 권장사항 네트워크 보안 구성 교육 문서에 설명된 대로 인증서를 애플리케이션과 통합하고 맞춤 네트워크 보안 구성을 만들면 됩니다.

하지만 서드 파티 애플리케이션 개발자는 Google Play 서비스 APK에서 발생하는 트래픽의 네트워크 보안 구성에 영향을 줄 수 없으므로 이 방법을 사용하면 문제가 부분적으로만 해결될 가능성이 큽니다.

이전의 기존 기기에서 사용할 수 있는 유일한 방법은 최종 사용자 기기에 적용되는 회사 그룹 정책에 따라 설치되어 추가한 CA나 최종 사용자 자신이 설치하여 추가한 CA를 사용하는 것입니다.

iOS Trust Store

Apple은 신뢰할 수 있는 기본 루트 인증서 세트를 핸드셋 사용자에게 직접 보여주지 않지만 해당 회사에는 다음 Apple 지원 문서에 제공된 iOS 버전 5 이상의 신뢰할 수 있는 루트 CA 세트의 링크가 있습니다.

하지만 iOS 기기에 설치된 모든 추가 인증서는 Settings > General > Profile에 표시됩니다. 추가 인증서가 설치되지 않은 경우 Profile 메뉴 항목이 표시되지 않을 수 있습니다.

다음 표에는 위의 소스를 기반으로 iOS 버전별로 가장 중요한 루트 인증서의 이용 가능 여부가 표시됩니다.

iOS 버전	GTS Root R1	GlobalSign Root CA - R1	GlobalSign Root R2(2021년 12월 15일까지 유효)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3 이상

시스템 루트 인증서 저장소는 어디에 있으며 어떻게 업데이트할 수 있나요?

기본 루트 인증서 저장소의 위치는 운영체제 및 사용되는 SSL/TLS 라이브러리에 따라 다릅니다. 하지만 대부분의 Linux 배포판에서 기본 루트 인증서는 다음 경로 중 하나에 있습니다.

/usr/local/share/ca-certificates: Debian, Ubuntu, 이전 RHEL 및 CentOS 버전
/etc/pki/ca-trust/source/anchors 및 /usr/share/pki/ca-trust-source: Fedora, 최신 RHEL 및 CentOS 버전
/var/lib/ca-certificates: OpenSUSE

다른 인증서 경로에는 다음과 같은 경로가 있습니다.

/etc/ssl/certs: Debian, Ubuntu
/etc/pki/tls/certs: RHEL, CentOS

이 디렉터리의 일부 인증서는 다른 디렉터리에 있는 파일의 심볼릭 링크일 수도 있습니다.

OpenSSL 루트 인증서 저장소

OpenSSL을 사용하는 애플리케이션의 경우 다음 명령어를 사용하여 기본 루트 인증서 저장소 등 설치된 구성요소의 구성된 위치를 확인할 수 있습니다.

openssl version -d

이 명령어는 라이브러리와 라이브러리의 구성이 포함된 최상위 디렉터리에 해당하는 OPENSSLDIR을 출력합니다.

OPENSSLDIR: "/usr/lib/ssl"

루트 인증서 저장소는 certs 하위 디렉터리에 있습니다.

ls -l /usr/lib/ssl/certs

lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs

…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

위의 예처럼 OpenSSL이 기본 시스템 루트 인증서 저장소를 사용하는 경우 최상위의 시스템 루트 인증서 저장소는 어디에 있으며 어떻게 업데이트할 수 있나요? 섹션을 참고하여 시스템 루트 인증서 번들이 최신 상태를 유지하도록 하세요.

openssl을 가져오는 방법은 OpenSSL 가져오기 섹션을 참고하세요.

Java 루트 인증서 저장소

Java 애플리케이션은 자체 루트 인증서 저장소를 사용할 수도 있는데, Linux 시스템에서 이 저장소는 일반적으로 /etc/pki/java/cacerts 또는 /usr/share/ca-certificates-java에 있으며, 이는 Java keytool 명령줄 도구를 사용하여 관리할 수 있습니다.

개별 인증서를 Java 인증서 저장소로 가져오려면 다음 명령어를 실행합니다.

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

cert.pem을 각각의 권장되는 루트 인증서에 해당하는 인증서 파일로 바꾸고, alias를 고유하고 의미 있는 인증서 별칭으로 바꿉니다. 또한 certs.jks를 현재 환경에서 사용되는 인증서 데이터베이스 파일로 바꿉니다.

자세한 내용은 다음 Oracle 및 Stack Overflow 문서를 참고하세요.

Mozilla NSS 루트 인증서 저장소

Mozilla NNS를 사용하는 애플리케이션에서는 일반적으로 /etc/pki/nssdb에 있는 시스템 전체 인증서 데이터베이스 또는 ${HOME}/.pki/nssdb 아래의 사용자별 기본 저장소를 기본으로 사용할 수도 있습니다.

NSS 데이터베이스를 업데이트하려면 certutil 도구를 사용합니다.

개별 인증서 파일을 NSS 데이터베이스로 가져오려면 다음 명령어를 실행합니다.

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

cert.pem을 각 권장 루트 인증서에 해당하는 인증서 파일로 바꾸고, cert-name을 의미 있는 인증서 닉네임으로 바꿉니다. 또한 certdir을 현재 환경에서 사용되는 인증서 데이터베이스 경로로 바꿉니다.

자세한 내용은 공식 NSS Tools certutil 설명서와 운영체제 문서를 참고하세요.

Microsoft .NET 루트 인증서 저장소

Windows .NET 개발자는 다음 Microsoft 문서에서 루트 인증서 저장소를 업데이트하는 데 유용한 정보를 찾을 수 있습니다.

인증서 파일 형식

PEM 파일이란 무엇인가요?

PEM(Privacy-Enhanced Mail)은 RFC 7468의 공식 표준에 따라 지정된 암호화 인증서, 키 등의 저장 및 전송을 위한 사실상의 표준 텍스트 파일 형식입니다.

파일 형식 자체는 인간이 읽을 수 있지만 Base64 로 인코딩된 바이너리 인증서 데이터 정보는 그렇지 않습니다. 하지만 PEM 사양을 사용하면 텍스트로 인코딩된 인증서 본문 앞이나 뒤에 설명 텍스트를 표시할 수 있으며 많은 도구에서 이 기능을 사용하여 인증서에서 가장 관련성 높은 데이터 요소의 명확한 텍스트 요약도 제공합니다.

openssl과 같은 도구는 전체 인증서를 인간이 읽을 수 있는 형식으로 디코딩하는 데 사용할 수도 있습니다. 자세한 내용은 PEM 인증서를 사람이 읽을 수 있는 형태로 인쇄하는 방법 섹션을 참고하세요.

'.crt' 파일이란 무엇인가요?

인증서를 PEM 형식으로 내보낼 수 있는 도구에서는 일반적으로 파일 확장자 '.crt'를 사용하여 파일에서 텍스트 인코딩을 사용한다는 것을 나타냅니다.

DER 파일이란 무엇인가요?

DER(Distinguished Encoding Rules)은 인증서를 인코딩하기 위한 표준 바이너리 형식입니다. PEM 파일의 인증서는 일반적으로 Base64로 인코딩된 DER 인증서입니다.

'.cer' 파일이란 무엇인가요?

접미어가 '.cer'인 내보낸 파일에는 PEM으로 인코딩된 인증서, 더 일반적으로는 바이너리, DER로 인코딩된 인증서가 포함될 수도 있습니다. 기준에 따라 '.cer' 파일에는 일반적으로 인증서가 하나만 포함됩니다.

시스템이 roots.pem에서 모든 인증서 가져오기를 거부함

일부 시스템(예: Java keytool)은 PEM 파일에 여러 인증서가 포함되어 있어도 하나의 인증서만 가져올 수 있습니다. 파일을 먼저 분할할 수 있는 방법은 roots.pem에서 개별 인증서를 추출하려면 어떻게 해야 하나요? 질문을 참고하세요.

roots.pem에서 개별 인증서를 추출하려면 어떻게 해야 하나요?

다음과 같이 간단한 bash 스크립트를 사용하여 roots.pem을 구성요소 인증서로 분할할 수 있습니다.

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

이렇게 하면 여기 표시된 것과 비슷한 개별 PEM 파일이 여러 개 생성됩니다.

ls -l *.pem

-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

그런 다음 02265526.pem과 같은 개별 PEM 파일을 별도로 가져오거나 인증서 저장소에서 허용되는 파일 형식으로 추가 변환할 수 있습니다.

PEM 파일과 내 시스템에서 지원하는 형식 간에 변환하는 방법

OpenSSL 툴킷 명령줄 도구 openssl은 일반적으로 사용되는 모든 인증서 파일 형식 간에 파일을 변환하는 데 사용할 수 있습니다. 다음은 PEM 파일에서 가장 일반적으로 사용되는 인증서 파일 형식으로 변환하는 방법입니다.

사용 가능한 옵션의 전체 목록은 공식 OpenSSL 명령줄 유틸리티 문서를 참고하세요.

openssl을 가져오는 방법은 OpenSSL 가져오기 섹션을 참고하세요.

PEM 파일을 DER로 변환하려면 어떻게 해야 하나요?

openssl을 사용하여 다음 명령어를 실행하면 파일을 PEM에서 DER로 변환할 수 있습니다.

openssl x509 -in roots.pem -outform der -out roots.der

PEM 파일을 PKCS #7로 변환하려면 어떻게 해야 하나요?

openssl을 사용하여 다음 명령어를 실행하면 파일을 PEM에서 PKCS #7로 변환할 수 있습니다.

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b

PEM 파일을 PKCS #12(PFX)로 변환하려면 어떻게 해야 하나요?

openssl을 사용하여 다음 명령어를 실행하면 파일을 PEM에서 PKCS #12로 변환할 수 있습니다.

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

PKCS #12 보관 파일을 만들 때 파일 비밀번호를 제공해야 하며 PKCS #12 파일을 시스템으로 즉시 가져오지 않을 경우 비밀번호를 안전한 곳에 보관해야 합니다.

루트 인증서 저장소의 인증서 표시, 인쇄, 내보내기

Java 키 저장소의 인증서를 PEM 파일로 내보내려면 어떻게 해야 하나요?

keytool을 사용하면 다음 명령어를 실행하여 인증서 저장소의 모든 인증서를 각 인증서를 내보내는 데 사용할 수 있는 별칭과 함께 표시할 수 있습니다.

keytool -v -list -keystore certs.jks

certs.jks를 현재 환경에서 사용되는 인증서 데이터베이스 파일로 바꾸면 됩니다. 이 명령어는 인증서를 내보내려는 경우에 필요한 각 인증서의 별칭도 표시해 줍니다.

개별 인증서를 PEM 형식으로 내보내려면 다음 명령어를 실행하세요.

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

certs.jks를 현재 환경에서 사용되는 인증서 데이터베이스 파일로 바꾸고, 내보내려는 인증서에 해당하는 alias 및 alias.pem을 제공하면 됩니다.

자세한 내용은 Java 플랫폼, 표준 버전 도구 참조: keytool 설명서를 참고하세요.

NSS 루트 인증서 저장소의 인증서를 PEM 파일로 내보내려면 어떻게 해야 하나요?

certutil을 사용하면 다음 명령어를 실행하여 인증서 저장소의 모든 인증서를 각 인증서를 내보내는 데 사용할 수 있는 닉네임과 함께 표시할 수 있습니다.

certutil -L -d certdir

certdir을 현재 환경에서 사용되는 인증서 데이터베이스 경로로 바꾸면 됩니다. 이 명령어는 인증서를 내보내려는 경우에 필요한 각 인증서의 닉네임도 표시해 줍니다.

개별 인증서를 PEM 형식으로 내보내려면 다음 명령어를 실행하세요.

certutil -L -n cert-name -a -d certdir > cert.pem

certdir을 현재 환경에서 사용되는 인증서 데이터베이스 경로로 바꾸고, 내보내려는 인증서에 해당하는 cert-name 및 cert.pem을 제공하면 됩니다.

자세한 내용은 공식 NSS Tools certutil 설명서와 운영체제 문서를 참고하세요.

PEM 인증서를 인간이 읽을 수 있는 형태로 인쇄하는 방법

다음 예에서는 다음 콘텐츠가 포함된 GTS_Root_R1.pem 파일이 있다고 가정합니다.

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----

OpenSSL을 사용하여 인증서 파일 인쇄

다음 명령어를 실행하면

openssl x509 -in GTS_Root_R1.pem -text

다음과 비슷한 결과가 출력됩니다.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

openssl을 가져오는 방법은 OpenSSL 가져오기 섹션을 참고하세요.

Java Keytool을 사용하여 인증서 인쇄

다음 명령어를 실행하면

keytool -printcert -file GTS_Root_R1.pem

다음과 비슷한 결과가 출력됩니다.

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

keytool을 가져오는 방법은 Java Keytool 가져오기를 참고하세요.

루트 인증서 저장소에 설치된 인증서를 확인하려면 어떻게 해야 하나요?

운영체제 및 SSL/TLS 라이브러리에 따라 다릅니다. 하지만 루트 인증서 저장소에서 인증서를 가져오거나 내보낼 수 있는 도구에서는 일반적으로 설치된 인증서를 표시할 수 있는 방법도 제공합니다.

또한 신뢰할 수 있는 루트 인증서를 PEM 파일로 내보냈거나 루트 인증서 저장소에 이미 저장된 PEM 파일이 포함되어 있는 경우 일반 텍스트 파일 형식이므로 텍스트 편집기에서 파일을 열 수 있습니다.

PEM 파일에 라벨을 적절히 지정하고 연결된 인증 기관의 사람이 읽을 수 있는 정보를 제공할 수 있습니다(예: 신뢰할 수 있는 Google 루트 CA 번들).

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

파일에 인증서 부분만 포함될 수도 있습니다. 이러한 경우 파일 이름(예: GTS_Root_R1.pem)이 인증서가 속한 CA를 나타낼 수도 있습니다. -----BEGIN CERTIFICATE----- 및 -----END CERTIFICATE----- 토큰 사이의 인증서 문자열도 CA마다 고유합니다.

하지만 위의 도구가 없어도 신뢰할 수 있는 Google 루트 CA 번들의 각 인증서에 라벨이 제대로 지정되므로 Issuer를 사용하거나 PEM 파일 인증서 문자열을 비교하여 번들의 루트 CA를 루트 인증서 저장소의 인증서와 확실하게 일치시킬 수 있습니다.

웹브라우저에서 자체 루트 인증서 저장소를 사용하거나 운영체제에서 제공하는 기본 인증서를 사용할 수도 있습니다. 하지만 모든 최신 브라우저에서는 브라우저에서 신뢰하는 루트 CA 세트를 관리하거나 적어도 볼 수 있습니다. 자세한 내용은 JavaScript 애플리케이션이 손상될 위험이 있나요?를 참고하세요.

휴대전화의 경우 확인 방법은 휴대전화에서 신뢰할 수 있는 루트 인증서를 확인하려면 어떻게 해야 하나요?를 참고하세요.

부록

추가 정보가 필요하신가요?

항상 운영체제 문서, 애플리케이션 프로그래밍 언어 문서 및 애플리케이션에서 사용 중인 외부 라이브러리의 문서를 참고하세요.

이 FAQ를 포함한 다른 모든 정보 출처는 오래되거나 정확하지 않을 수 있으며 신뢰할 수 있는 것으로 간주해서는 안 됩니다. 하지만 Stack Exchange Q&A 커뮤니티 및 AdamW on Linux and more, confirm blog 등 많은 사이트에서도 유용한 정보를 찾을 수 있습니다.

Google Trust Services FAQ도 참고하세요.

인증서 고정과 같은 고급 주제에 대한 자세한 내용은 OWASP (Open Web Application Security Project) 인증서 및 공개 키 고정 문서 및 요약본 고정을 참고하세요. Android 관련 정보는 Android 보안 및 개인 정보 보호 권장사항 HTTPS 및 SSL을 사용한 보안 교육 문서를 참고하세요. Android의 인증서 및 공개 키 고정에 관한 내용은 Matthew Dolan 의 블로그 게시물 Android 보안: SSL 고정을 참고하세요.

Android 보안 및 개인 정보 보호 권장사항 네트워크 보안 구성 교육 문서 및 JeroenHD 블로그 게시물 Android 7 Nougat 및 인증 기관에는 Android에서 신뢰할 수 있는 추가 인증서를 관리하는 데 대한 자세한 내용이 포함되어 있습니다.

AOSP에서 신뢰하는 루트 CA 목록 전체는 ca-certificates Git 저장소를 참고하세요. 비공식 Android 포크를 기반으로 하는 버전(예: LineageOS)의 경우 OS 공급업체가 제공하는 적절한 저장소를 참고하세요.