Google Maps Platform 루트 CA 이전 관련 FAQ

일반 정보

문제 해결

신뢰할 수 있는 인증서 관리

부록

일반 정보

변경된 사항은 무엇인가요?

개요

Google은 여러 해에 걸쳐 HTTPS에서 사용하는 TLS/SSL 인터넷 보안의 기본인 암호화 서명 루트 인증서를 발급하고 사용하기 위한 계획을 실행하고 있습니다.

현재 Google Maps Platform의 TLS 보안은 Symantec 소유의 매우 널리 알려지고 신뢰할 수 있는 인증 기관(CA)인 GeoTrust Global CA에서 발급한 루트 인증서를 통해 보장됩니다. 실제로 모든 TLS 클라이언트(예: 웹브라우저, 스마트폰, 애플리케이션 서버)는 이 루트 인증서를 인식하며, 따라서 이 인증서를 사용하여 Google Maps Platform에 안전하게 연결할 수 있습니다.

Google에서는 2020년 초까지 모든 Google Maps Platform 서비스를 Google의 자체 인증 기관 Google Trust Services(GTS)에서 발급한 루트 인증서로 이전할 계획입니다.

중간 단계로 2018년 초 Google Maps Platform이 광범위하게 신뢰되는 GlobalSign(GS)의 다른 루트 인증서로 이전되었습니다. Google은 원활한 인증서 전환을 위해 이 루트 인증서 및 GlobalSign에서 이 인증서를 발급하는 데 사용한 CA의 사용권을 구매했습니다.

대부분의 TLS 클라이언트는 이미 GlobalSign 루트 인증서를 인식하므로 이 초기 변경사항의 영향을 받지 않고 Google Maps Platform을 사용할 수 있습니다.

하지만 특히 삽입된 기기와 같은 일부 전문가 사용 사례 또는 매우 오래된 기존 브라우저 또는 운영체제를 사용하는 사용자의 경우 일부 클라이언트에 GlobalSign 루트 인증서가 없을 수도 있습니다. 이 클라이언트는 Google Maps Platform 연결을 보호하기 위해 인증서를 사용하여 업데이트해야 합니다. Google에서 이 클라이언트를 식별할 수 없으므로 애플리케이션 소유자가 자체 애플리케이션에서 필요한 인증을 처리해야 합니다. Google Trust Services에서는 이 작업에 도움이 되도록 GTS 사이트에서 HTTPS 테스트 엔드포인트를 제공합니다. 자세한 기술 정보는 아래를 참고하세요.

GTS 루트 인증서로 이전이 시작될 때까지 대부분의 시스템에 동일한 사항이 적용될 가능성이 크지만 이 문서의 권장 사항을 따르면 전문가 시스템인 경우에도 일반적으로 원활하게 이전할 수 있습니다.

기술 요약

2017년 3월 16일에 Google Maps Platform 프리미엄 요금제의 고객지원 포털에, 그 전에 Google 보안 블로그에 발표된 바와 같이 Google은 자체 루트 CA GPS를 만들었습니다. Google Maps Platform은 다른 Google 서비스와 함께 GTS 루트 CA에서 서명한 TLS 인증서로 점진적으로 전환될 예정입니다.

중간 단계로 Google은 광범위하게 신뢰되는 GS Root R2 CA를 구매했습니다. Google Maps Platform은 2017년 말에 GeoTrust 루트 인증서에서 이 인증서로 이전이 시작되어 2108년 초에 이전이 완료되었습니다.

거의 모든 TLS 클라이언트가 GS Root R2 인증서로 사전 구성되거나 일반 소프트웨어 업데이트를 통해 인증서를 받지만 애플리케이션이 이 인증서를 인식하지 못하는 클라이언트에서 Google Maps Platform에 연결되는 경우 애플리케이션 개발자는 인증서로 클라이언트를 테스트하고 필요한 경우 업데이트해야 합니다.

GS Root R2 인증서 및 모든 GTS 루트 인증서는 GTS 사이트를 통해 제공됩니다. 테스트를 위해 GTS 사이트에서는 엔드포인트에 각 CA에서 서명한 TLS 인증서도 제공합니다. 특히 클라이언트는 GS Root R2 테스트 엔드포인트에 TLS 연결을 설정할 수 있는 경우 GS Root R2 인증서를 신뢰하며 예정된 변경사항의 영향을 받지 않습니다.

Google에서는 적어도 2018년 말까지 GS Root R2 CA를 사용합니다. 그 후에는 Google Maps Platform이 GTS CA로 직접 전환되거나 경우에 따라 GS Root R3 CA를 포함한 타사 루트 CA로 돌아갈 수도 있습니다.

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

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

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

예. 루트 CA 이전은 모든 Google 서비스와 API에서 발생하지만 타임라인은 서비스별로 다를 수 있습니다. 하지만 애플리케이션이 Google 샘플 PEM 파일에 포함된 권장 인증서 세트를 신뢰하는 것이 확인된 후에는 애플리케이션에서 호출하는 Google API 또는 서비스에 관계없이 나중에 루트 인증서를 이전하는 동안 애플리케이션을 사용할 수 있어야 합니다. 자세한 내용은 Google 샘플 PEM 파일의 모든 루트 인증서를 설치해야 하나요?를 참고하세요.

인증서 저장소를 업데이트해야 하는지 확인하려면 어떻게 해야 하나요?

GTS 사이트에서 각 루트 CA와 함께 포함된 테스트 엔드포인트에 대해 애플리케이션 환경을 테스트하세요. GS Root R2 테스트 엔드포인트Google 인증서 테스트 샌드박스에 TLS 연결을 설정할 수 있는 경우 적어도 2018년 말까지는 문제가 없습니다.

따라서 항상 프로덕션 환경을 완전히 최신 상태로 유지하고 패치할 수 없으면 이제 Google 샘플 PEM 파일의 모든 인증서를 설치하여 미래에도 시스템을 사용할 수 있도록 설정하는 것이 좋습니다.

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

대부분의 플랫폼에서 사용할 수 있는 명령줄 도구 curl은 광범위한 설정 테스트 옵션을 제공합니다. curl을 가져오는 방법은 curl 가져오기 섹션을 참고하세요.

기본 인증서 저장소 테스트
# Google certificate test sandbox
$ curl -vvI https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI https://good.r4demo.pki.goog/
$ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
Google 루트 CA 번들 확인
Google 샘플 PEM 파일을 다운로드한 후 다음 단계를 따릅니다.
# Google certificate test sandbox
$ curl -vvI --cacert roots.pem https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI --cacert roots.pem https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI --cacert roots.pem https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI --cacert roots.pem https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI --cacert roots.pem https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI --cacert roots.pem https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI --cacert roots.pem https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI --cacert roots.pem https://good.r4demo.pki.goog/
$ openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -CAfile roots.pem -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null

이전은 어떻게 진행되나요?

이전은 언제 실행되나요?

GS Root R2에 고정된 중간 CA에서 발급한 인증서로 전환하는 첫 번째 이전 단계는 2017년 말에 시작되어 2018년 상반기에 완료되었습니다.

이후 이전 단계의 일정은 앞으로 몇 년 이내에, 단 GS Root R2 2021 인증서가 만료되기 한참 전에 발표될 예정입니다.

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

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

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

Google Maps Platform의 수를 늘리면 새 데이터 센터로 이전함에 따라 개발자가 새 인증서를 받기 시작합니다. 클라이언트 요청이 지리적으로 인접한 데이터 센터의 서버로 전달되는 경향이 있기 때문에 변경사항은 어느 정도 현지화됩니다. 누가 언제 어디서 영향을 받을지 미리 확실하게 알 수 없으므로 모든 고객이 미리 Google 루트 CA 이전의 다음 단계 한참 전에 미래에도 시스템을 사용할 수 있는지 확인하는 것이 좋습니다.

주의사항

필요한 루트 인증서로 구성되지 않은 클라이언트는 Google Maps Platform에 대한 TLS 연결을 확인할 수 없습니다. 이 경우 클라이언트는 일반적으로 인증서 유효성 검사에 실패했다는 경고를 표시합니다. TLS 구성에 따라 클라이언트가 Google Maps Platform 요청을 계속 발행하거나 요청 진행을 거부할 수도 있습니다.

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

GTS FAQ전송 계층 보안(TLS) 클라이언트가 Google Maps Platform과 통신하기 위한 최소 권장 요구사항은 무엇인가요? 섹션을 참고하세요.

Google Maps Platform에는 추가 요구사항이 적용되지 않습니다.

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

애플리케이션은 개발자가 설정한 제한사항 없이 시스템 인증서 저장소를 사용합니다.

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

아직 유지되고 정기적으로 업데이트를 받는 주요 OS(예: Ubuntu, Red Hat, Windows 7 이상 또는 Server 2008 이상, OS X)를 사용하는 경우 기본 인증서 저장소에 항상 GS Root R2 인증서가 포함되어야 합니다.

더 이상 업데이트를 받지 않는 기존 OS 버전을 사용하는 경우 GS Root R2 인증서가 있을 수도 있고 없을 수도 있습니다. 예를 들어 Windows XP SP2에는 인증서가 포함되어 있지만 Windows XP SP1에는 포함되어 있지 않습니다. 기존 기기는 인증서를 신뢰하는지 테스트해야 합니다.

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

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

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

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

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

애플리케이션이 자체 인증서 번들을 사용하거나 인증서 고정과 같은 고급 보안 기능을 사용합니다.

인증서 번들을 직접 업데이트해야 합니다. Google 샘플 PEM 파일의 모든 루트 인증서를 설치해야 하나요?에 설명된 대로 Google 샘플 PEM 파일의 모든 루트 인증서를 인증서 저장소로 가져오는 것이 좋습니다.

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

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

Google 샘플 PEM 파일의 모든 루트 인증서를 설치해야 하나요?

지금 한 번에 미래에도 시스템을 사용할 수 있도록 설정하려면, 특히 시스템에 정기적으로, 규칙적으로 운영체제 업데이트를 적용하지 않거나 예를 들어 애플리케이션에 대해 자체 인증서 번들을 유지하는 경우 Google 샘플 PEM 파일의 모든 인증서를 설치하는 것이 좋습니다.

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

Google 샘플 PEM 파일의 루트 인증서만 설치하고 루트 인증서를 사용하여 루트 인증서에 고정된 전체 인증서 체인의 진위 여부를 확인해야 합니다. 개별 서버 인증서(예: 호스트 maps.googleapis.com에서 제공하는 인증서)는 물론 중간 CA(예: GIAG3, GTS CA 1O1 또는 GIAG4)의 경우에도 마찬가지입니다.

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

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

GlobalSign R2 루트 CA는 잘 삽입되며 대부분의 최신 브라우저에서 신뢰합니다. 따라서 이 브라우저에서는 한동안 Google 서비스에 계속 연결할 수 있습니다. 브라우저가 적극적으로 관리되는 경우 특정 시점에 다른 모든 Google 루트 CA도 지원하게 될 것이 거의 확실합니다.

그러나 Google Maps JavaScript API 자체는 지원되는 브라우저에서만 작동하므로 사용하는 데 문제가 없도록 표시된 브라우저 중 하나를 사용하고 브라우저를 최신 상태로 유지하는 것이 좋습니다.

모바일 애플리케이션이 손상될 위험이 있나요?

기기 제조업체로부터 여전히 정기적으로 업데이트를 받는 Android 및 Apple 기기는 미래에도 사용할 수 있을 것으로 예상됩니다. 대부분의 이전 Android 휴대전화 모델에는 최소한 GS Root R2 및 GS Root R3 인증서가 모두 포함되어 있습니다. 단 신뢰할 수 있는 인증서 목록은 핸드셋 제조업체, 기기 모델, Android 버전마다 다를 수 있습니다. Google Nexus 및 Pixel 브랜드 기기에 사용되는 최신 Android 오픈소스 프로젝트(AOSP) 버전도 기본적으로 GS Root R4를 신뢰합니다. 출시된 Android 버전 중에서 GTS 루트 CA를 지원하는 버전은 여전히 아주 적습니다.

iOS 기기의 경우 Apple이 지원 페이지에 각 iOS 버전에 대해 신뢰할 수 있는 루트 CA의 목록을 유지합니다. 하지만 iOS 5 이상의 모든 버전은 GS Root R2와 R3, 버전 7 이상은 GS Root R4도 지원합니다. 현재 Android 버전과 마찬가지로 이 문서 작성 시점에는 GTS 루트 CA가 아직 지원되지 않습니다.

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

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

Google은 널리 사용되고 신뢰할 수 있는 루트 인증서 번들을 유지하는 모든 주요 타사와 협력하고 있습니다. 여기에는 Apple, Microsoft와 같은 운영체제 제조업체 및 Google 자체 Android와 ChromeOS팀, Mozilla, Apple, Microsoft와 같은 브라우저 개발업체 및 Google 자체 Chrome팀. 휴대폰, 셋톱 박스, TV, 게임 콘솔, 프린터 등 하드웨어 제조업체가 포함됩니다.

타사 인증서 포함 타임라인은 거의 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 및 tcpdump 가져오기

대부분의 Linux 배포판은 두 도구를 모두 제공하지만 사전 컴파일된 다른 OS용 wireshark 버전은 https://www.wireshark.org에서 찾을 수 있습니다. tcpdump의 소스 코드 및 LibPCAP는 https://www.tcpdump.org에서 찾을 수 있습니다.

자바 Keytool 가져오기

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

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

기본 작업은 Google 샘플 PEM 파일의 필수 루트 인증서를 애플리케이션에서 사용하는 인증서 신뢰 저장소에 설치하는 것입니다. 신뢰할 수 있는 인증서 관리 섹션에도 유용한 정보가 있습니다.
  1. 시스템 관리자와 협력하여 로컬 인증서 저장소를 업그레이드합니다.
  2. 이 FAQ에 사용 중인 시스템에 해당하는 포인터가 있는지 확인합니다.
  3. 플랫폼 또는 시스템별 지원이 더 필요한 경우 시스템 공급자가 제공하는 기술 지원 채널에 문의합니다.
  4. 일반 지원의 경우 Google Maps Platform 지원팀에 문의하기 섹션에 설명된 대로 지원팀에 문의합니다.
  5. 이전 관련 추가 업데이트를 받으려면 공개 문제 67842936에 별표를 표시하세요.

Google Maps Platform 지원팀에 문의하기

초기 문제 해결

일반적인 문제 해결 방법은 인증서 저장소를 업데이트해야 하는지 확인하려면 어떻게 해야 하나요?를 참고하세요.

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

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

  1. 영향을 받은 서버의 위치
  2. 서비스에서 호출하는 Google IP 주소
  3. 이 문제의 영향을 받는 API
  4. 문제가 시작된 정확한 시간
  5. 다음 명령어의 출력:
    # Google Maps Platform service
    $ curl -vvI https://maps.googleapis.com/
    # Google Search site
    $ curl -vvI https://www.google.com/
    # Google certificate test sandbox
    $ curl -vvI https://cert-test.sandbox.google.com/
    # GS Root R2
    $ curl -vvI https://good.gsr2demo.pki.goog/
    # GS Root R3
    $ curl -vvI https://valid.r3.roots.globalsign.com/
    # GTS Root R1
    $ curl -vvI https://good.r1demo.pki.goog/
    $ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
    $ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
    

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

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/<username>/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 libssh2/1.4.2
> Host: cert-test.sandbox.google.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 암호화 연결을 통해 성공적으로 전송되고 있음을 나타냅니다.
* 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=*.googleapis.com
*  start date: Jul 29 17:24:40 2019 GMT
*  expire date: Oct 27 17:24:40 2019 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.
> HEAD / HTTP/1.1
> User-Agent: curl/7.64.0
> Host: maps.googleapis.com
> Accept: */*
>
< HTTP/1.1 302 Found
수신된 서버 인증서를 사람이 읽을 수 있는 형태로 인쇄하려면 어떻게 해야 하나요?
출력이 PEM 형식이라고 가정하면(예: openssl s_client ... -showcerts의 출력) 다음 단계에 따라 제공된 인증서를 인쇄할 수 있습니다.
  1. 머리글과 바닥글을 포함하여 Base64로 인코딩된 전체 인증서를 복사합니다.
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    
  2. openssl x509 -inform pem -noout -text
    
  3. 복사 버퍼의 내용을 터미널에 붙여넣습니다.
  4. Return 키를 누릅니다.
입력 및 출력 예는 아래 수신된 서버 인증서를 사람이 읽을 수 있는 형태로 인쇄하려면 어떻게 해야 하나요? 섹션을 참고하세요.

OpenSSL의 Google 인증서는 어떤 형식인가요?

GlobalSign Root CA - R2에 고정된 새 인증서

Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com
   i:C = US, O = Google Trust Services, CN = GTS CA 1O1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1
   i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com

issuer=C = US, O = Google Trust Services, CN = GTS CA 1O1

신뢰할 수 있는 인증서 관리

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

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 버전 GS Root R2 GS Root R3 GS Root R4 GTS
2.3, 3.2, 4.x, 5.0
5.1, 6.x, 7.x, 8.x, 9
10

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

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

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

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

iOS Trust Store

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

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

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

iOS 버전 GS Root R2 GS Root R3 GS Root R4 GTS
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 Feb 13  2017 /usr/lib/ssl/certs -> /etc/ssl/certs
$ ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 212177 Sep  5 00:45 ca-certificates.crt
…
lrwxrwxrwx 1 root root     62 Sep  5 00:39 GlobalSign_Root_CA_-_R2.pem -> /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt
…

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

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

Mozilla NSS

Mozilla NNS를 사용하는 애플리케이션에서는 기본적으로 일반적으로 /etc/pki/nssdb에 있는 시스템 전체 인증서 데이터베이스 또는 ${HOME}/.pki/nssdb 아래의 사용자별 기본 저장소를 사용할 수도 있습니다. NSS를 업데이트하려면 certutil 도구 문서의 새 인증서를 추가하는 방법 및 공식 OS 문서를 참고하세요.

Microsoft .NET

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

자바

자바 애플리케이션은 자체 인증서 저장소(Linux 시스템의 경우 일반적으로 /etc/pki/java/cacerts 또는 /usr/share/ca-certificates-java에 있음)를 사용할 수도 있습니다. Oracle keytool 명령줄 도구를 사용하여 자바 인증서 저장소를 업데이트하는 방법은 다음 Stack Overflow 및 Oracle 문서를 참고하세요.

PEM 파일이란 무엇인가요?

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

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

openssl와 같은 도구는 전체 인증서를 사람이 읽을 수 있는 형식으로 디코딩하는 데 사용할 수도 있습니다. 자세한 내용은 수신된 서버 인증서를 사람이 읽을 수 있는 형태로 인쇄하려면 어떻게 해야 하나요? 섹션을 참고하세요.

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

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

DER 파일이란 무엇인가요?

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

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

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

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

일부 시스템에서는 단일 인증서가 포함된 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}"\
    $(printf %b $(openssl x509 -in ${f} -noout -issuer|sed -e 's/"//g'|sed -e 's#/#_#g')).pem;\
done
이렇게 하면 아래 표시된 것과 비슷한 개별 PEM 파일이 여러 개 생성됩니다.
issuer=C=BE,O=GlobalSignnv-sa,OU=RootCA,CN=GlobalSignRootCA.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=ComodoCALimited,CN=AAACertificateServices.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOECCCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODORSACertificationAuthority.pem
issuer=C=IE,O=Baltimore,OU=CyberTrust,CN=BaltimoreCyberTrustRoot.pem
issuer=C=SE,O=AddTrustAB,OU=AddTrustExternalTTPNetwork,CN=AddTrustExternalCARoot.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustCommercial.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustNetworking.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremiumECC.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremium.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertHighAssuranceEVRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertTrustedRootG4.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2009Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-G2.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2012Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-EC1.pem
issuer=C=US,O=Entrust,Inc.,OU=www.entrust.net_CPSisincorporatedbyreference,OU=(c)2006Entrust,Inc.,CN=EntrustRootCertificationAuthority.pem
issuer=C=US,O=GeoTrustInc.,CN=GeoTrustGlobalCA.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR1.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR2.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR3.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR4.pem
issuer=C=US,O=StarfieldTechnologies,Inc.,OU=StarfieldClass2CertificationAuthority.pem
issuer=C=US,O=TheGoDaddyGroup,Inc.,OU=GoDaddyClass2CertificationAuthority.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com,Inc.,CN=GoDaddyRootCertificateAuthority-G2.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=StarfieldTechnologies,Inc.,CN=StarfieldRootCertificateAuthority-G2.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustECCCertificationAuthority.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustRSACertificationAuthority.pem
issuer=O=Cybertrust,Inc,CN=CybertrustGlobalRoot.pem
issuer=O=Entrust.net,OU=www.entrust.net_CPS_2048incorp.byref.(limitsliab.),OU=(c)1999Entrust.netLimited,CN=Entrust.netCertificationAuthority(2048).pem
issuer=OU=GlobalSignECCRootCA-R4,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignECCRootCA-R5,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R2,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R3,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R6,O=GlobalSign,CN=GlobalSign.pem
roots.pem
그런 다음 PEM 파일 issuer=….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 파일을 시스템으로 즉시 가져오지 않을 경우 비밀번호를 안전한 곳에 보관해야 합니다.

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

Mozilla NSS certutil 도구 문서 및 Red Hat 커뮤니티 사이트 토론 go8.db에서 인증서를 .pem 파일로 내보내기를 확인하세요.

PEM 인증서를 사람이 읽을 수 있는 형식으로 인쇄하려면 어떻게 해야 하나요?

다음 예에서는 다음 콘텐츠가 포함된 GlobalSign_Root_CA_-_R2.pem 파일이 있다고 가정합니다.
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

OpenSSL을 사용하여 인증서 인쇄

다음 명령어를 실행하면
openssl x509 -in GlobalSign_Root_CA_-_R2.pem -text
인증서 전에 다음 행이 출력됩니다.
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:0f:86:26:e6:0d
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Validity
            Not Before: Dec 15 08:00:00 2006 GMT
            Not After : Dec 15 08:00:00 2021 GMT
        Subject: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a6:cf:24:0e:be:2e:6f:28:99:45:42:c4:ab:3e:
                    21:54:9b:0b:d3:7f:84:70:fa:12:b3:cb:bf:87:5f:
                    c6:7f:86:d3:b2:30:5c:d6:fd:ad:f1:7b:dc:e5:f8:
                    60:96:09:92:10:f5:d0:53:de:fb:7b:7e:73:88:ac:
                    52:88:7b:4a:a6:ca:49:a6:5e:a8:a7:8c:5a:11:bc:
                    7a:82:eb:be:8c:e9:b3:ac:96:25:07:97:4a:99:2a:
                    07:2f:b4:1e:77:bf:8a:0f:b5:02:7c:1b:96:b8:c5:
                    b9:3a:2c:bc:d6:12:b9:eb:59:7d:e2:d0:06:86:5f:
                    5e:49:6a:b5:39:5e:88:34:ec:bc:78:0c:08:98:84:
                    6c:a8:cd:4b:b4:a0:7d:0c:79:4d:f0:b8:2d:cb:21:
                    ca:d5:6c:5b:7d:e1:a0:29:84:a1:f9:d3:94:49:cb:
                    24:62:91:20:bc:dd:0b:d5:d9:cc:f9:ea:27:0a:2b:
                    73:91:c6:9d:1b:ac:c8:cb:e8:e0:a0:f4:2f:90:8b:
                    4d:fb:b0:36:1b:f6:19:7a:85:e0:6d:f2:61:13:88:
                    5c:9f:e0:93:0a:51:97:8a:5a:ce:af:ab:d5:f7:aa:
                    09:aa:60:bd:dc:d9:5f:df:72:a9:60:13:5e:00:01:
                    c9:4a:fa:3f:a4:ea:07:03:21:02:8e:82:ca:03:c2:
                    9b:8f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.globalsign.net/root-r2.crl

            X509v3 Authority Key Identifier:
                keyid:9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E

    Signature Algorithm: sha1WithRSAEncryption
         99:81:53:87:1c:68:97:86:91:ec:e0:4a:b8:44:0b:ab:81:ac:
         27:4f:d6:c1:b8:1c:43:78:b3:0c:9a:fc:ea:2c:3c:6e:61:1b:
         4d:4b:29:f5:9f:05:1d:26:c1:b8:e9:83:00:62:45:b6:a9:08:
         93:b9:a9:33:4b:18:9a:c2:f8:87:88:4e:db:dd:71:34:1a:c1:
         54:da:46:3f:e0:d3:2a:ab:6d:54:22:f5:3a:62:cd:20:6f:ba:
         29:89:d7:dd:91:ee:d3:5c:a2:3e:a1:5b:41:f5:df:e5:64:43:
         2d:e9:d5:39:ab:d2:a2:df:b7:8b:d0:c0:80:19:1c:45:c0:2d:
         8c:e8:f8:2d:a4:74:56:49:c5:05:b5:4f:15:de:6e:44:78:39:
         87:a8:7e:bb:f3:79:18:91:bb:f4:6f:9d:c1:f0:8c:35:8c:5d:
         01:fb:c3:6d:b9:ef:44:6d:79:46:31:7e:0a:fe:a9:82:c1:ff:
         ef:ab:6e:20:c4:50:c9:5f:9d:4d:9b:17:8c:0c:e5:01:c9:a0:
         41:6a:73:53:fa:a5:50:b4:6e:25:0f:fb:4c:18:f4:fd:52:d9:
         8e:69:b1:e8:11:0f:de:88:d8:fb:1d:49:f7:aa:de:95:cf:20:
         78:c2:60:12:db:25:40:8c:6a:fc:7e:42:38:40:64:12:f7:9e:
         81:e1:93:2e

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

자바 Keytool을 사용하여 인증서 인쇄

다음 명령어를 실행하면
keytool -printcert -file GlobalSign_Root_CA_-_R2.pem
다음 행이 출력됩니다.
Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Issuer:
CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Serial number:
400000000010f8626e60d
Valid from: Fri Dec 15 09:00:00 CET 2006 until: Wed Dec 15
09:00:00 CET 2021
Certificate fingerprints:
   MD5:
94:14:77:7E:3E:5E:FD:8F:30:BD:41:B0:CF:E7:D0:30
   SHA1:
75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE
   SHA256:
CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
   Signature algorithm name: SHA1withRSA
   Version: 3

Extensions:

#1:
ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

#2: ObjectId:
2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]
#3: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
     [URIName: http://crl.globalsign.net/root-r2.crl]
]]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]
#5: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

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

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

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

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

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

# Operating CA: GlobalSign
# Issuer: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Subject: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Label: "GlobalSign Root CA - R2"
# Serial: 4835703278459682885658125
# MD5 Fingerprint: 94:14:77:7e:3e:5e:fd:8f:30:bd:41:b0:cf:e7:d0:30
# SHA1 Fingerprint: 75:e0:ab:b6:13:85:12:27:1c:04:f8:5f:dd:de:38:e4:b7:24:2e:fe
# SHA256 Fingerprint: ca:42:dd:41:74:5f:d0:b8:1e:b9:02:36:2c:f9:d8:bf:71:9d:a1:bd:1b:1e:fc:94:6f:5b:4c:99:f4:2c:1b:9e
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

파일에 인증서 부분만 포함될 수도 있습니다. 이러한 경우 파일 이름(예: GlobalSign_Root_CA_-_R2.pem)이 인증서가 속한 CA를 나타낼 수도 있습니다. -----BEGIN CERTIFICATE----------END CERTIFICATE----- 토큰 사이의 인증서 문자열은 CA마다 고유하며 다른 방법으로 CA를 식별할 수 없는 경우 PEM 파일의 이 문자열을 비교하면 됩니다.

따라서 Google 샘플 PEM 파일의 각 인증서를 인증서 저장소에서 추출한 PEM 파일과 비교할 수 있습니다. Google 루트 CA 번들의 각 인증서에 라벨이 제대로 지정되므로 인증서 저장소 PEM 파일에 라벨이 지정되지 않은 경우 이미 인증서 저장소에 있는 인증서를 확인하고 아직 추가해야 하는 인증서를 확인할 수 있습니다.

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

부록

추가 정보가 필요하세요?

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

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

인증서 고정과 같은 고급 주제에 대한 자세한 내용은 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 공급업체가 제공하는 적절한 저장소를 참고하세요.