Google Maps Platform ルート認証局(CA)の移行に関するよくある質問

全般情報

トラブルシューティング

信頼できる証明書の管理

付録

全般情報

現在の状況

概要

Google は、独自のルート証明書を発行して使用する取り組みを複数年にわたって進めています。ルート証明書は、HTTPS で使用される TLS / SSL インターネット セキュリティの基盤となる暗号署名です。

現在、Google Maps Platform の TLS セキュリティは、GeoTrust Global CA が発行するルート証明書によって保証されています。GeoTrust Global は広く信頼されている有名な認証局(CA)で、Symantec が所有しています。ほぼすべての TLS クライアント(ウェブブラウザ、スマートフォン、アプリケーション サーバーなど)が GeoTrust Global CA のルート証明書を認識するため、この証明書を使用すれば Google Maps Platform サーバーへ安全に接続できます。

2020 年代前半には、すべての Google Maps Platform サービスを Google 独自の認証局 Google Trust Services(GTS)が発行する証明書へ移行する予定です。

暫定措置として、2018 年前半に GlobalSign(GS)の別のルート証明書へ Google Maps Platform を移行しました。証明書の移行をスムーズに進めるため、Google は、このルート証明書の使用権(および GlobalSign がこのルート証明書を発行するために使用していた CA)を取得しました。

ほとんどの TLS クライアントは GlobalSign のルート証明書をすでに信頼しているため、この初期の変更は Google Maps Platform の使用に影響を与えません。

ただし、ユースケースが特殊(組み込みデバイスなど)であったり、ユーザーのブラウザやオペレーティング システムが非常に古い場合、クライアントによっては GlobalSign のルート証明書が追加されていない可能性があります。これらのクライアントが Google Maps Platform の接続を保護するには、証明書を更新する必要があります。Google では該当するクライアントを特定できません。アプリケーション オーナーが、それぞれのアプリケーションで必要な検証を行う必要があります。そのための手段として、Google Trust Services(GTS)サイトで HTTPS テスト エンドポイントを提供しています。技術的な詳細は、この後の説明をご覧ください。

GTS ルート証明書への移行に伴う影響はほとんどのシステムにあてはまりますが、このドキュメントの推奨事項に従うことで、特殊なシステムであってもスムーズに移行できます。

技術面の概要

2017 年 1 月の Google セキュリティ ブログ、および 2017 年 3 月 16 日に Google Maps Platform プレミアム プランのカスタマー サポート ポータルでお知らせしたように、Google は独自のルート認証局 Google Trust Services を開設しました。他の Google サービスと同様、Google Maps Platform も、ルート認証局 Google Trust Services(GTS)によって署名された TLS 証明書へ段階的に移行いたします。

それまでの過程として、Google は、広く信頼されている既存の GS Root R2 CA を取得しました。Google Maps Platform については、2017 年後半に GeoTrust ルート証明書からこの証明書への移行を開始し、2018 年初頭に完了しています。

ほとんどの TLS クライアントは、GS Root R2 証明書を使用して事前構成されているか、通常のソフトウェア アップデートでこの証明書を取得します。ただし、この証明書を認識しないクライアントから Google Maps Platform に接続する場合は、クライアントをテストし、必要であればこの証明書を使用するように更新する必要があります。

GS Root R2 証明書およびすべての GTS ルート証明書は、GTS サイトで入手できます。さらに、GTS サイトでは、各 CA によって署名された TLS 証明書を備えた、テスト用のエンドポイントも提供しています。たとえば、クライアントが GS Root R2 テスト エンドポイントへ TLS 接続した場合、そのクライアントは GS Root R2 証明書を信頼するため、今後の変更による影響を受けません。

少なくとも 2018 年末まで GS Root R2 CA を使用します。その後は、Google Maps Platform を GTS CA へ直接移行する予定ですが、場合によっては、サードパーティのルート CA(GS ルート R3 など)に戻す可能性もあります。

この移行プロセスに関する最新情報を入手するには、どうすればよいですか?

公開イシュー 67842936 にスターを付けて、最新情報をご確認ください。移行プロセス中、多くのお客様にかかわる問題が発生した場合は、この「よくある質問」も更新されます。

複数の Google サービスを利用しています。ルート認証局の移行はこれらのサービスに影響を与えますか?

はい。ルート 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 Root 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

移行プロセスについて

移行のスケジュール

移行の第 1 段階は、中間 CA(GS Root R2)が発行する証明書への切り替えです。この作業は 2017 年後半に開始し、2018 年前半に完了しました。

今後の移行フェーズのスケジュールについては、GS Root R2 2021 証明書の有効期限が切れる前に、十分な余裕をもってお知らせいたします。

Google サービスの段階的な移行計画

  • まず、1 つのデータセンターでのみ運用を開始します。
  • その後、他のデータセンターにも段階的に展開し、最終的にはすべてのデータセンターに適用します。
  • いずれかの段階で重大な問題が検出された場合は、テストを一時的にロールバックして、その問題に対処します。
  • 状況を確認しながら、Google サービスの移行を段階的に進め、最終的にはすべての Google サービスを新しい証明書へ移行します。

いつ、どこで、どのような利用者が影響を受けますか?

Google Maps Platform デベロッパーの数が増え、新しいデータセンターへの移行が進むと、新しい証明書を取得できるようになります。クライアント リクエストは、地理的に近いデータセンターのサーバーに転送される傾向があるため、実際の状況は地域によって多少異なります。いつ、どこで、どのお客様が影響を受けるかについては、現時点で明確にお答えできません。Google ルート CA の移行が次段階へ進む前に、十分な時間的余裕をみて、システムが引き続き運用できる状態であることを確認するようおすすめします。

注意事項

必要なルート証明書を使用して構成されていないクライアントは、Google Maps Platform への TLS 接続を検証できません。その場合、通常、証明書の検証エラーを知らせる警告が発行されます。クライアントの TLS 構成によっては、Google Maps Platform リクエストを引き続き発行できます。このリクエストの続行を拒否することもできます。

TLS クライアントが Google Maps Platform と通信するための最小要件は何ですか?

Google Trust Services のよくある質問で、「Transport Layer Security(TLS)クライアントが Google と通信するための推奨最小要件を教えてください」をご覧ください。

Google Maps Platform と通信するための追加要件はありません。

移行に伴い、問題が発生する可能性があるのはどのようなアプリケーションですか?

アプリケーションでシステム証明書ストアを使用しており、デベロッパーが何も制限していない場合

Google Maps Platform ウェブサービス アプリケーション

現在もサポート対象であり、定期的にアップデートされる主要 OS(Ubuntu、Red Hat、Windows 7 以降、Windows Server 2008 以降、OS X など)を使用している場合、デフォルトの証明書ストアには GS Root R2 証明書がすでに含まれています。

アップデートが終了した古い OS バージョンを使用している場合は、必ずしも GS Root R2 証明書が含まれているとは限りません。たとえば、Windows XP SP2 には GS Root R2 証明書が含まれていますが、Windows XP SP1 には含まれていません。レガシー デバイスをテストし、GS Root R2 証明書を信頼することを確認する必要があります。

エンドユーザー デバイスから Google Maps Platform ウェブサービスを直接呼び出すモバイルアプリの場合、モバイルアプリが動作しなくなる可能性はありますか?のガイドラインをご覧ください。

クライアント側の Google Maps Platform アプリケーション

通常、Google Maps JavaScript API アプリケーションは、そのアプリケーションを実行するウェブブラウザのルート証明書を使用します。詳しくは、Google Maps JavaScript API アプリケーションが動作しなくなる可能性はありますか?をご覧ください。

Google Maps または Places SDK を使用するネイティブ モバイルアプリ(Android および iOS)には、Google Maps Platform ウェブサービスを呼び出すアプリと同じルールが適用されます。

詳しくは、モバイルアプリが動作しなくなる可能性はありますか?をご覧ください。

アプリケーションで独自の証明書バンドルまたは高度なセキュリティ機能(証明書ピニングなど)を使用している場合

証明書バンドルをご自身で更新する必要があります。Google サンプル PEM ファイルのすべてのルート証明書をインストールする必要がありますか?に記載されているように、Google サンプル PEM ファイルのすべてのルート証明書を証明書ストアへインポートすることをおすすめします。

アプリケーションの接続先となる Google ドメインの証明書または公開鍵を制限(ピニング)している場合、その証明書と公開鍵をアプリケーションの信頼リストに追加する必要があります。

証明書や公開鍵のピニングについて詳しくは、その他の関連情報に記載されている外部リソースをご覧ください。

Google サンプル PEM ファイルのすべてのルート証明書をインストールする必要がありますか?

一度の対応で、今後も引き続きシステムを運用できるようにしたい場合は、Google サンプル PEM ファイルに含まれているすべての証明書をインストールしてください。特に、オペレーティング システムのアップデートを定期的に適用しない場合や、アプリケーションで独自の証明書バンドルを使用する場合などは、これらの証明書をインストールすることをおすすめします。

中間 CA 証明書をインストールしてはいけないのはなぜですか?

必ず Google サンプル PEM ファイルのルート証明書をインストールし、そのルート証明書を使用して、証明書チェーン全体の信頼性を検証してください。これは、個々のサーバー証明書(ホスト maps.googleapis.com によって提供される証明書など)に加え、Google の中間 CA(GIAG3、GTS CA 1O1、GIAG4 など)にも適用されます。

最新の TLS ライブラリの実装では、ルート認証局が信頼されていれば、証明書チェーンの信頼性を自動的に検証できます。

Google Maps JavaScript API アプリケーションが動作しなくなる可能性はありますか?

GlobalSign R2 ルート CA の証明書は、最新のほとんどのブラウザに組み込まれており、信頼されています。したがって、今後しばらくは、これらのブラウザから Google サービスへ引き続き接続できます。ブラウザを綿密に管理している場合は、その他すべての Google ルート CA もサポートされるようになります。

ただし、Google Maps JavaScript API 自体は、サポート対象のブラウザでのみ動作が保証されます。使用中に問題が発生しないようにするため、サポート対象のいずれかのブラウザを使用し、常に最新の状態を維持することをおすすめします。

モバイルアプリが動作しなくなる可能性はありますか?

デバイス メーカーから定期的にアップデートを受け取る Android デバイスと Apple デバイスは、今後も問題なく使用できます。旧モデルの Android スマートフォンの場合、信頼できる証明書のリストはスマートフォン メーカー、デバイスモデル、Android のバージョンによって異なりますが、少なくとも GS Root R2 と GS Root R3 の証明書は両方とも含まれています。Google Nexus デバイスや Google Pixel デバイスで使用される Android オープンソース プロジェクト(AOSP)の最新バージョンは、デフォルトで GS Root R4 も信頼しています。GTS ルート CA については、リリースされているどの Android バージョンでも最小限のサポートとなります。

iOS デバイスの場合、最新の各 iOS バージョンについて、信頼するルート CA のリストを Apple のサポートページで確認できます。なお、iOS バージョン 5 以降は GS Root R2 と R3 をサポートしており、iOS バージョン 7 以降は GS Root R4 もサポートしています。現在の Android バージョンと同様、このドキュメントの執筆時点では、GTS ルート CA はまだサポートされていません。

詳しくは、信頼できるルート証明書をスマートフォンで確認するには、どうすればよいですか?をご覧ください。

ブラウザやオペレーティング システムに Google Trust Services のルート証明書が追加される時期は?

Google は、広く使用され、信頼されているルート証明書バンドルを管理する主要なすべてのサードパーティと連携しています。たとえば、Apple、Microsoft などのオペレーティング システム メーカー、Google 内の Android チームや ChromeOS チーム、Mozilla、Apple、Microsoft などのブラウザ デベロッパー、Google 内の Chrome チーム、さらにはさまざまなハードウェア メーカー(スマートフォン、セットトップ ボックス、テレビ、ゲーム機、プリンタなど)と連携しています。

サードパーティの証明書追加スケジュールは 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 をお使いの場合、コンパイル済みの wiresharkhttps://www.wireshark.org で入手できます。LibPCAP および tcpdump のソースコードは https://www.tcpdump.org で入手できます。

Java keytool の入手方法

keytool コマンドライン ツールは、Java Development Kit(JDK)または Java Runtime Environment(JRE)のすべてのバージョンに組み込まれています。これらをインストールすると、keytool. を使用できるようになります。ただし、アプリケーションを Java でビルドしていない限り、ルート証明書の検証で keytool を使用する必要はありません。

サービスが停止した場合はどうすればよいですか?

まず、Google サンプル PEM ファイルで必要なルート証明書を確認し、アプリケーションが使用する証明書信頼ストアにそれらの証明書をインストールします。 なお、信頼できる証明書の管理にも、有用な情報が記載されています。
  1. システム管理者と協力して、ローカル証明書ストアをアップグレードします。
  2. この「よくある質問」で、ご使用のシステムに関するアドバイスを確認します。
  3. プラットフォームまたはシステムに固有のサポートが必要な場合は、システム プロバイダが提供するテクニカル サポート チャネルにお問い合わせください。
  4. 全般的なサポートが必要な場合は、Google のサポートチームにお問い合わせください(Google Maps Platform サポートへのお問い合わせを参照)。
  5. 移行に関する最新情報を取得するには、Public Issue 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 handshake が成功したことを意味します。
使用された TLS ライブラリとルート証明書バンドル

-vvI フラグを指定して curl を実行すると、使用した証明書ストアも出力されます。ただし、次のように、実際の出力はシステムによって異なります。

Red Hat Linux マシンで curl (NSS にリンク)を実行した場合の出力は、次のようになります。

* 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

Google ルート証明書 PEM ファイルを使用する Ubuntu または Debian Linux マシンで、--cacert フラグを指定した場合の出力は次のようになります。

* 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 handshake に失敗した場合
以下の行は、信頼できないサーバー証明書が原因で、TLS handshake 中に接続が終了したことを示しています。「>」または「<」で始まるデバッグ出力がないことからも、接続に失敗したことがわかります。
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
TLS handshake に成功した場合
以下のコードは、TLS handshake に成功した例を示しています。接続を暗号化するための暗号スイートと、受理されたサーバー証明書がリスト表示されます。さらに、「>」または「<」で始まる行は、TLS 暗号化接続を介して、ペイロード HTTP トラフィックが正常に送信されていることを示しています。
* 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 キーを押します。
入力と出力の例は、この後の人が判読できる形式で PEM 証明書を出力するには、どうすればよいですか?でご確認ください。

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 バージョンごとに示しています。これは、現在、Android Virtual Device(AVD)で提供されているシステム イメージを使用し、手動で検証したものです。システム イメージがない場合は、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 バージョンは今でも広く使用されており、そこで信頼されている一連のルート証明書は、デバイス自体が有効寿命を迎えた後も数年にわたってサービスを提供します。

Android 7.0 以降では安全性が強化され、そのアプリでのみ信頼する証明書をアプリ開発者が追加できるようになっています。具体的には、Android 向けデベロッパー ガイドのネットワーク セキュリティ構成(セキュリティとプライバシーに関する推奨事項)に記載されているように、証明書をアプリにバンドルし、独自のネットワーク セキュリティ構成を作成します。

ただし、サードパーティのアプリ開発者は、Google Play Services APK から発生するトラフィックのネットワーク セキュリティ構成を変更できないため、この方法も適用が限定的といえます。

古いデバイスの場合、会社のグループ ポリシーに従ってエンドユーザーのデバイスにインストールされた CA、またはエンドユーザー自身がデバイスに追加した CA を使用するしか方法がありません。

iOS: トラストストア

Apple では、信頼できるルート証明書のデフォルト セットをスマートフォン ユーザーに直接提示していません。ただし、iOS バージョン 5 以降の信頼できるルート CA は、Apple サポートの記事(iOS で利用できる信頼されたルート証明書の一覧iOS 5 および iOS 6: 信用できるルート証明書の一覧)のリンクで確認できます。

また、iOS デバイスにインストールされたその他の証明書は、[設定] > [一般] > [プロファイル] に表示されます。追加の証明書がインストールされていない場合は、[プロファイル] メニュー項目が表示されない可能性があります。

次の表は、上記の情報源に基づき、最も重要なルート証明書の可用性を 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 NSS 対応のアプリケーションでは、デフォルトで、システム全体の証明書データベース(通常は /etc/pki/nssdb に配置)またはユーザー固有のストア(${HOME}/.pki/nssdb に配置)を使用する可能性があります。NSS を更新する際は、certutil ツールのドキュメント(新しい証明書を追加する方法)および OS の公式ドキュメントをご覧ください。

Microsoft .NET

以下の Microsoft の記事は、Windows .NET 開発者が証明書ストアを更新する際に役立ちます。

Java

Java アプリケーションでは、それぞれ独自の証明書ストアを使用できます。Linux システムの場合、通常、この証明書ストアは /etc/pki/java/cacerts または /usr/share/ca-certificates-java に配置されます。Oracle の keytool コマンドライン ツールを使用して Java 証明書ストアを更新する方法については、以下の Stack Overflow と Oracle の記事をご覧ください。

PEM ファイルとは何ですか?

Privacy-Enhanced Mail(PEM)は、暗号化された証明書やキーを保存および送信する際に使用される、業界標準のテキスト ファイル形式です。RFC 7468 で標準規格として定められています。

PEM ファイル形式自体は人による判読が可能ですが、Base64 でエンコードされたバイナリ証明書データは判読不可能です。ただし、PEM 仕様では、テキスト エンコードされた証明書本文の前または後に、説明テキストを追加することができます。多くのツールがこの機能を使用し、証明書で最も関連性の高いデータ要素のサマリーをプレーン テキストで提供しています。

また、openssl などのツールを使用して、証明書全体を人間が判読できる形式にデコードすることも可能です。詳しくは、PEM 証明書を人が判読できる形式で出力するには、どうすればよいですか?をご覧ください。

「.crt」ファイルとは何ですか?

証明書を PEM 形式でエクスポートできるツールでは、通常、ファイル拡張子「.crt」を使用して、そのファイルがテキスト エンコーディング対応であることを示します。

DER ファイルとは何ですか?

Distinguished Encoding Rules(DER)は、証明書のエンコーディングで使用される標準バイナリ形式です。PEM ファイルの証明書は、通常、Base64 でエンコードされた DER 証明書です。

「.cer」ファイルとは何ですか?

エクスポートしたファイルの拡張子が「.cer」の場合、PEM でエンコードされた証明書が含まれている場合もありますが、通常は、DER でエンコードされたバイナリ形式の証明書です。慣例により、通常、「.cer」ファイルに含まれる「.cer」ファイルは 1 つだけです。

roots.pem からすべての証明書をインポートできません

システによっては、1 つの証明書を含む 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 コミュニティ サイトのディスカッション(cert8.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 の入手方法をご覧ください。

Java 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 を入手する方法は、Java 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 ごとに一意であることが保証されています。他に方法がない場合は、PEM ファイルのこれらの文字列を比較することで CA を特定できます。

したがって、Google サンプル PEM ファイルの各証明書と、証明書ストアから取得した PEM ファイルと比較することができます。Google ルート CA バンドルの各証明書は適切にラベル付けされているため、証明書ストアの PEM ファイルにラベルがない場合でも、証明書ストアに追加されている証明書と、これから追加する必要がある証明書を正確に特定できます。

スマートフォンでの手順については、信頼できるルート証明書をスマートフォンで確認するには、どうすればよいですか?をご覧ください。

付録

その他の関連情報

主要な情報源として、まず、オペレーティング システムのドキュメント、ご使用のアプリケーション プログラミング言語のドキュメント、アプリケーションが利用する外部ライブラリのドキュメントをご覧ください。

この「よくある質問」を含め、その他のドキュメントは情報が古かったり、間違っていたりする可能性があるため、信頼できる情報源として使用しないでください。ただし、Stack Exchange のさまざまな質疑応答コミュニティAdamW on Linux and more サイト、confirm blog などでは有益な情報が得られます。また、GTS のよくある質問や、X.509 証明書と SSL を使用して通信を保護する方法もご覧ください。

証明書のピニングなど、高度な機能について詳しくは、Open Web Application Security Project(OWASP)の記事およびクイック リファレンスをご覧ください。Android に固有の情報は、Android 公式トレーニング ガイドの HTTPS と SSL を使用したセキュリティをご覧ください。Android における証明書と公開鍵のピニングについては、Matthew Dolan のブログ記事 Android のセキュリティ: SSL ピニングをご覧ください。

Android トレーニング ガイドのネットワーク セキュリティ構成および JeroenHD のブログ記事(Android 7 Nougat and certificate authorities)では、信頼できる証明書を Android で管理する方法をさらに詳しく習得できます。

AOSP が信頼するルート CA の一覧は、ca-certificates Git リポジトリをご覧ください。LineageOS など、非公式の Android フォークをベースにしたバージョンについては、OS ベンダーが提供するリポジトリをご覧ください。