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

このドキュメントでは以下の項目について説明します。

詳細については、この件についてをご覧ください。

用語

以下は、このドキュメントを読む際に知っておく必要がある重要な用語のリストです。関連用語の概要については、Google Trust Services に関するよくある質問をご覧ください。

TLS/SSL 証明書
証明書によって、暗号鍵が ID にバインドされます。
TLS/SSL 証明書は、ウェブサイトへのアクセスを認証し、安全な接続を確立するために使用されます。証明書は、認証局という機関によって発行され、暗号方式で署名されます。
ブラウザは、信頼できる認証局によって発行された証明書を基に、情報が適切なサーバーに送信されていることと、転送時に暗号化されていることを認識します。
セキュア ソケット レイヤ（SSL）
セキュア ソケット レイヤは、インターネット通信の暗号化用に、最も広くデプロイされているプロトコルです。SSL プロトコルは安全性が低いと認識されるようになったため、Google サービスではサポートが終了しました。
Transport Layer Security（TLS）
Transport Layer Security は SSL の後継です。
認証局（CA）
認証局とは、デバイスやユーザーのための旅券局のようなものです。エンティティ（ウェブサイトなど）が本物であることを証明するために、暗号方式で保護されたドキュメント（証明書）を発行します。
CA の役割は、証明書を発行する前に、証明書内の名前が証明書をリクエストしているユーザーまたはエンティティにリンクされているかを確認することです。
認証局という用語は、Google Trust Services などの組織を指す場合と、証明書を発行するシステムを指す場合があります。
公開鍵基盤（PKI）
公開鍵基盤は、認証局が証明書リクエスト元の身元を確認し、その検証を証明する証明書を作成し、インターネット ユーザーがその証明書を信頼できるようにする一連の技術、ポリシー、手順です。
公開鍵暗号は、これを可能にするテクノロジーです。
PKI は内部ネットワークでも使用されますが、最も一般的なユースケースはウェブでの暗号化された通信を可能にすることです。ウェブブラウザは、ルート証明書ストアに含まれる CA によって発行された証明書を信頼します。
公開鍵暗号
公開鍵暗号は、鍵ペアを使用する暗号の一種です。1 つの鍵は公開鍵と見なされ、広く配布できます。もう 1 つの鍵は秘密鍵と見なされ、秘密にしておく必要があります。
公開鍵で暗号化されたデータは、対応する秘密鍵で復号できます。また、その逆も可能です。
これにより、デジタル署名と公開鍵暗号化の概念が実現します。これらは、2 者が事前に秘密情報を交換することなく、互いに認証し、暗号化されたデータを共有できる TLS などのプロトコルの基本的な構成要素です。
ルート証明書ストア（またはトラストストア）
ルート証明書ストアは、アプリケーション ソフトウェアのサプライヤーが信頼する認証局のグループで構成されます。ほとんどのウェブブラウザとオペレーティング システムには、独自のルート証明書ストアがあります。
ルート証明書ストアに追加できるのは、アプリケーション ソフトウェアのサプライヤーが定める厳格な要件を満たした認証局のみです。
一般に、CA/Browser Forum の要件などの業界標準へのコンプライアンスがこれに該当します。
ルート認証局
ルート認証局（または、厳密にはその証明書）は、証明書チェーンの最上位にある証明書です。
ルート CA 証明書は通常、自己署名されています。この証明書に関連付けられる秘密鍵は、安全性が高い場所にオフライン状態で保管され、不正アクセスから保護されます。
中間認証局
中間認証局（より厳密にはその証明書）は、証明書チェーン内の他の証明書に署名するために使用される証明書です。
中間 CA は、主にルート CA 証明書をオフライン状態にしたままで、オンライン証明書の発行を可能にするためのものです。
中間 CA は下位 CA とも呼ばれます。
発行元の認証局
発行元の認証局（より厳密には証明書）は、証明書チェーン内の最下位の証明書に署名するために使用する証明書です。
この最下位の証明書は、一般的にサブスクライバー証明書、エンド エンティティ証明書、リーフ証明書などと呼ばれます。このドキュメントでは、サーバー証明書という用語も使用します。
証明書チェーン
証明書は、発行元にリンクされます（発行元が暗号方式で署名します）。証明書チェーンは、リーフ証明書、すべての発行元証明書、ルート証明書で構成されます。
クロス署名
アプリケーション ソフトウェアのサプライヤーのクライアントは、ルート証明書ストアを更新して、そのサービスによって信頼される新しい CA 証明書を追加する必要があります。その新しい CA 証明書を含むサービスが広く使用されるまでには、時間がかかります。
古いクライアントとの互換性を高めるために、確立済みの別の CA によって CA 証明書に「クロス署名」することができます。これにより、同じ ID（名前と鍵のペア）に対して 2 つ目の CA 証明書を効果的に作成できます。
ルート証明書ストアに含まれる CA に応じて、クライアントは信頼できるルートまでの別の証明書チェーンを構築します。

全般情報

目的をたずねられた場合:

概要: https://pki.goog/faq/#connecting-to-google のガイダンスに従わないと、今後証明書関連の停止が発生する可能性が高くなります。

概要

2017 年から、Google は独自のルート証明書を発行して使用するためのプロジェクトを複数年にわたって進めています。このルート証明書は、HTTPS で使用される TLS インターネット セキュリティの基盤となる暗号署名です。

第 1 段階の後、Google Maps Platform サービスの TLS セキュリティは、GS Root R2 によって提供されています。GS Root R2 は広く信頼されている有名なルート認証局（CA）で、Google が GMO GlobalSign から取得したものです。これは、Google 独自の自己発行の Google Trust Services（GTS）ルート認証局への移行を容易にするためです。

このルート証明書は、ほぼすべての TLS クライアント（ウェブブラウザ、スマートフォン、アプリケーション サーバーなど）から信頼されているため、移行の第 1 段階で、Google Maps Platform サーバーへの安全な接続を確立できました。

ただし、CA は設計上、有効期限を超過すると有効な証明書を発行できません。GS Root R2 は、2021 年 12 月 15 日に有効期限が切れたため、Google は、独自のルート CA の GTS Root R1 によって発行された証明書を使用して、自社サービスを新しい CA の GTS Root R1 Cross に移行しました。

最新のオペレーティング システムと TLS クライアント ライブラリの大部分は、すでに GTS ルート CA を信頼していますが、ほとんどの従来型システムでもスムーズに移行できるように、Google は、利用可能な最も古い信頼性の高いルート CA の 1 つである GlobalSign Root CA - R1 を使用して、GMO GlobalSign からクロス署名を取得しました。

そのため、大部分のお客様の Google Maps Platform クライアントは、信頼性の高いこれらのルート CA のいずれか（または両方）を認識できるため、移行の第 2 段階の影響は受けません。

これは、2018 年の移行の第 1 段階で対応していただいたお客様にも当てはまります。つまり、その時点で Google の指示に沿って、Google の信頼できるルート CA バンドルをすべてインストールしていただいたお客様です。このファイルに対する更新を少なくとも 6 か月に 1 回確認し、信頼ストアを更新する必要があります。

Google Maps Platform サービスへの接続に問題がある場合は、次の場合にシステムを確認する必要があります。

  • 非標準または従来型のプラットフォームでサービスが実行されているか、独自のルート証明書ストアを管理している
  • 2017～2018 年の Google のルート CA 移行の第 1 段階では対応しなかった、または Google の信頼できるルート CA バンドルからすべての証明書をインストールしなかった

上記に当てはまる場合、今回の移行段階中に Google Maps Platform を中断なく使用できるようにするためには、推奨のルート証明書を使用してクライアントを更新していただく必要があります。

技術的な詳細については、以下のセクションを参照してください。一般的な手順については、ルート証明書ストアの更新が必要かどうかを確認する方法をご覧ください。

また、サービスが今後のルート CA の変更にも対応できるよう、ルート証明書ストアを上記の所定のルート CA バンドルと常に同期しておくことをおすすめします。ただし、この点については事前にお知らせいたします。詳細については、この移行プロセスに関する最新情報はどこで入手できますか？と、今後の移行に関する事前通知を受け取るには、どうすればよいですか？のセクションをご覧ください。

技術面の概要

2021 年 3 月 15 日に、Google セキュリティ ブログでお知らせしたとおり、2018 年初頭から Google Maps Platform で使用されていたルート認証局の GS Root R2 は、2021 年 12 月 15 日に有効期限が切れました。そのため、Google は新たに発行した CA の GTS Root R1 Cross に移行します。

最新の TLS クライアントとやステムは、ほぼすべてが GTS Root R1 証明書を使用して事前構成されているか、通常のソフトウェア更新でその証明書を取得するようになっています。また、GlobalSign Root CA - R1 は、従来型の古いシステムでも利用できます。

ただし、最低でも次の条件が両方当てはまる場合は、システムを確認してください。

  • 非標準または従来型のプラットフォームでサービスが実行されているか、独自のルート証明書ストアを管理している
  • 2017～2018 年の Google のルート CA 移行の第 1 段階では対応しなかった、または Google の信頼できるルート CA バンドルからすべての証明書をインストールしなかった

ルート証明書ストアの更新が必要かどうかを確認する方法では、システムに影響が生じるかどうかテストする際のガイダンスを提供しています。

詳細については、ルート証明書ストアを信頼できる Google Root CA バンドルと同期させるべきなのはなぜですか？をご覧ください。

この移行プロセスに関する最新情報はどこで入手できますか？

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

今後の移行に関する事前通知を受け取るには、どうすればよいですか？

新しいルート証明書は https://pki.goog/updates/ で発表されます。更新の通知を受け取るために登録できる RSS フィードもあります。新しいルートのみが発表されます。テニュア ルート間の証明書チェーンの変更は通知されず、いつでも発生する可能性があります。Google への信頼性の高い接続を確保するには、単一のルートまたは中間に固定してはならず、https://pki.goog/faq/#connecting-to-google で説明されている Google ルートの完全なセットを信頼する必要があります。

Google セキュリティ ブログをフォローすることをおすすめします。また、ブログで一般公開が発表された後は、できるだけ早くサービスごとのドキュメントも更新する予定です。

Google Maps Platform の情報通知も配信登録しましょう。Google では、多くのお客様に影響を及ぼす可能性がある変更についての最新情報を、フォーラムに定期的に投稿しています。

複数の Google サービスを利用している場合、ルート認証局の移行によってそうしたサービスに影響が生じますか？

はい。ルート CA の移行は、Google のすべてのサービスと API が対象となります（実際の移行スケジュールはサービスによって異なります）。ただし、Google Maps Platform クライアント アプリケーションで使用されるルート証明書ストアに、信頼できる Google Root CA バンドルに記載されているすべての CA が含まれていることを確認すれば、サービスは進行中の移行の影響を受けません。また、これらの CA を同期（少なくとも 6 か月ごとに 1 回）しておけば、今後のルート CA の変更にも対応できます。

詳細については、ルート証明書ストアを信頼できる Google Root CA バンドルと同期させるべきなのはなぜですか？と、移行に伴い、問題が発生する可能性があるのはどのようなアプリケーションですか？の質問をご覧ください。

以下のルート証明書ストアの更新が必要かどうかを確認する方法のセクションでも、システムテストの一般的な手順を説明しています。

ルート証明書ストアの更新が必要かどうかを確認する方法

https://pki.goog/repository/ の [ルート CA] セクションにあるすべてのルートを使用して、アプリケーション環境をテストします。

次の場合であれば、システムは通常、ルート CA の変更に対応できます。

  • 管理されているメインストリームのオペレーティング システム上でサービスが実行されており、オペレーティング システムと、サービスで使用されるライブラリの両方に常にパッチが適用されており、かつ独自のルート証明書ストアを管理していない場合。または以下に該当する場合:
  • 前述の推奨事項に即しており、信頼できる Google Root CA バンドルからすべてのルート CA をインストールし、信頼ストアを定期的に更新している場合。

影響を受ける可能性があるお客様には、以降のサービスの中断を避けるため、信頼できる Google Root CA バンドルから、証明書を直ちにインストールしていただく必要があります。

詳細については、ルート証明書ストアを信頼できる Google Root CA バンドルと同期させるべきなのはなぜですか？をご覧ください。

ルート証明書ストアの確認に使用できるツールはありますか？

curl と openssl の 2 つのコマンドライン ツールは、調査に役立つ場合があります。どちらもほとんどのプラットフォームで利用可能で、設定をテストするための幅広いオプションが用意されています。

curl を取得する方法については、以下の curl の入手方法をご覧ください。

以下に示す openssl コマンドはバージョン 1.1.1 以降用です。1.1.1 より前のバージョンはサポート対象外です。1.1.1 より前のバージョンを使用している場合は、必要に応じて、これらのコマンドをアップグレードまたは変更します。openssl を入手する方法については、以下の OpenSSL の入手方法をご覧ください。

その他の便利なツールの詳細については、以下の必要なツールはどこで取得できますか？のセクションをご覧ください。

具体的なテスト手順については、ルート証明書ストアの更新が必要かどうかを確認する方法をご覧ください。

デフォルトのルート証明書ストアをテストする

この例は GTS R1 のものです。テストはすべての GTS ルートに対して実施する必要があります。

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 Root CA バンドルを検証する

信頼できる Google Root CA バンドルをダウンロードしてから、次の手順に従います。

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

2017 年の Google ルート CA の移行はいつ、どのように実施されますか？

  1. 2017 年 1 月に発表された第 1 段階（GS Root R2 への移行）は、2017 年後半に開始され、2018 年上半期に終了しました。
  2. 第 2 段階（GTS Root R1 Cross への移行）は 2021 年 3 月に発表され、GS Root R2 の有効期限（2021 年 12 月 15 日）が切れるまでの数か月でロールアウトされました。

新しいルートのスケジュールについては、今後証明書の有効期限が切れる前に、十分な余裕をもってお知らせいたします。ただし、既存のルート間の移行についてはお知らせいたしません。

ルート証明書ストアを、信頼できる Google Root CA バンドルの所定のルート CA リストと同期させることで、今後の変化にアプリを対応させることができます。

詳しい背景については、質問のルート証明書ストアを信頼できる Google Root CA バンドルと同期させる必要があるのはなぜですか？をご覧ください。

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

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

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

Google Maps Platform デベロッパーの数が増え、新しいデータセンターへの移行が進むと、新しい証明書を取得できるようになります。クライアント リクエストは、地理的に近いデータセンターのサーバーに転送される傾向があるため、実際の状況は地域によって多少異なります。

いつ、どこで、どのお客様が影響を受けるかについては、現時点で明確にお答えできません。Google Root CA の移行が想定される場合は、十分な時間的余裕を持ってサービスを確認し、将来的な変更に対応できるようにしておくことをおすすめします。

詳しいガイダンスについては、ルート証明書ストアの更新が必要かどうかを確認する方法をご覧ください。

注意事項

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

クライアントの TLS 構成によっては、Google Maps Platform リクエストを引き続き発行できます。このリクエストの続行を拒否することもできます。

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

Google Maps Platform の証明書では、DNS サブジェクト代替名（SAN）が使用されるため、名前の左端にワイルドカードを含む SAN（*.googleapis.com など）に対応できるようにする必要があります。

レガシー TLS バージョン 1.0 と 1.1 は引き続きサポートされていますが、これらの使用は推奨されません。可能であれば TLS 1.3 を使用することをおすすめします。

その他の要件と推奨事項については、GTS に関するよくある質問の TLS クライアントを Google と通信させる場合の推奨要件は何ですか？と 多くの Google サービスで TLS 1.0 と TLS 1.1 を使用した接続が許可されているのはなぜですか？をご覧ください。

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

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

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

現在もサポート対象であり、定期的にアップデートされる主要 OS を使用している場合、デフォルトのルート証明書ストアには GTS Root 証明書がすでに含まれています。

アップデートが終了した古い OS バージョンを使用している場合は、必ずしも GTS Root 証明書が含まれているとは限りません。ただし、多くの場合、ルート証明書ストアには GlobalSign Root CA - R1（実績と信頼性でトップクラスのルート CA）が含まれています。このルート CA は、必要に応じて GTS ルートの相互署名に使用されます。

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

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

通常、Maps JavaScript API アプリケーションは、そのアプリケーションを実行するウェブブラウザのルート証明書を使用します。詳しくは、JavaScript アプリケーションに障害が発生するリスクはありますか？をご覧ください。

Maps SDK for Android、Maps SDK for iOS、Places SDK for Android、Places SDK for iOS のいずれかを使用するモバイルアプリには、Google Maps Platform ウェブサービスを呼び出すアプリと同じルールが適用されます。

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

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

証明書バンドルをご自身で更新する必要があります。質問のルート証明書ストアを信頼できる Google Root CA バンドルと同期させるべきなのはなぜですか？で説明されているように、信頼できる Google Root CA バンドルから、すべての証明書を独自のルート証明書ストアにインポートし、証明書ストアを定期的に更新することをおすすめします。

Google は、アプリケーションの接続先となる Google ドメインの証明書または公開鍵を制限（ピニング）することを推奨していません。ピン留めすると、破損のリスクが高まります。

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

ルート証明書ストアを信頼できる Google Root CA バンドルと同期させるべきなのはなぜですか？

信頼できる Google Root CA バンドルに含まれる、所定のルート CA のリストには、将来的に Google サービスで使用される可能性がある CA がすべて記載されています。

そのため、システムの将来性を考えた場合、ルート証明書ストアにバンドル内のすべての証明書が含まれていることを確認し、少なくとも 6 か月ごとに両者を同期させることを強くおすすめします。

これは、メンテナンスが行われていないバージョンのオペレーティング システムでサービスが実行されている場合や、その他の理由でオペレーティング システムとライブラリにパッチを常に適用しておくことができない場合、あるいは独自のルート証明書ストアを管理している場合に特に重要です。

今後のルート CA の移行に関する最新情報を確認する方法については、今後の移行に関する事前通知を受け取るには、どうすればよいですか？をご覧ください。ルート証明書ストアと所定のリストを常に同期させることで、今後の CA の変更によるサービスの中断を防ぐことができます。また、GTS Root R1 Cross と GlobalSign Root CA - R1 の有効期限が切れた後も、サービスを継続的に実行できるメリットもあります。

その他の推奨事項については、質問の Google サービスに接続するサービスを構築する場合、どの CA 証明書を信頼する必要がありますか？（GTS に関するよくある質問）もご確認ください。

リーフまたは中間 CA 証明書をインストールすべきでないのはなぜですか？

Google が新しい証明書を登録したり、中間 CA を切り替えたりする場合に、アプリケーションで障害が発生するリスクがあります。そうした登録や切り替えは、いずれも事前の通知なく行われる可能性があります。また、個々のサーバー証明書（maps.googleapis.com から提供される証明書など）と、Google の中間 CA（GTS Root R1 Cross など）の両方がそれに当てはまります。

サービスをそうしたケースから保護するには、信頼できる Google Root CA バンドルのルート証明書のみをインストールして使用し、それに関連付けられている証明書チェーン全体の信頼性を検証します。

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

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

GTS ルート証明書は、ほとんどの最新のブラウザによってすでに認識、信頼されています。また、GlobalSign のクロス署名を使用すれば、従来型ブラウザのエンドユーザーでも、移行をスムーズに行うことができます。これには、Maps JavaScript API で公式にサポートされているすべてのブラウザが含まれます。

最新のブラウザでは、エンドユーザーが信頼する証明書を検証、編集できるようになっています。正確な場所はブラウザによって異なりますが、通常、ブラウザの [設定] メニュー項目から証明書リストを表示できます。

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

デバイス メーカーから定期的にアップデートを受け取る Android デバイスと Apple iOS デバイスは、今後も問題なく使用できます。古い Android スマートフォン モデルのほとんどは、GlobalSign Root CA - R1 証明書は含まれていますが、信頼できる証明書のリストは、スマートフォンのメーカー、デバイスモデル、Android のバージョンによって異なる場合があります。

ただし、GTS Root R1 を含む GTS ルート CA のサポートは、10 より前のバージョンの Android では引き続き制限されることがあります。

iOS デバイスの場合、最新の各 iOS バージョンについて、信頼するルート CA のリストを Apple のサポートページで確認できます。ただし、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 チーム、さらにはさまざまなハードウェア メーカー（スマートフォン、セットトップ ボックス、テレビ、ゲーム機、プリンタなど）と連携しています。

したがって、積極的にメンテナンスされているシステムはすでに GTS のルート CA をサポートしている可能性が非常に高く、従来型のシステムでも GlobalSign Root CA - R1 をサポートしている可能性が高いです。このルート CA は、今後数年間にわたって Google が発行する多くの証明書のクロス署名に使用されます。

ただし、サードパーティの証明書追加スケジュールは 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 用の最初の 2 つのコンパイル済みバージョンは、https://www.wireshark.org で入手できます。

LibPCAP および LibPCAP のソースコードは https://www.tcpdump.org で入手できます。

これらの便利なツールに関するドキュメントは、Wireshark ユーザーガイド、Tshark の man ページ、Tcpdump の man ページで確認できます。

Java keytool の入手方法

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

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

まず、信頼できる Google Root CA バンドルから、アプリケーションで使用するルート証明書ストアに、必要なルート証明書をインストールします。

  1. システム管理者と協力して、ローカルのルート証明書ストアをアップグレードします。
  2. この「よくある質問」で、ご使用のシステムに関するアドバイスを確認します。
  3. プラットフォームまたはシステムに固有のサポートが必要な場合は、システム プロバイダが提供するテクニカル サポート チャネルにお問い合わせください。
  4. 全般的なサポートが必要な場合は、Google のサポートチームにお問い合わせください（Google Maps Platform サポートへのお問い合わせを参照）。注: プラットフォーム固有の問題については、ベスト エフォートのアドバイスとなることをご了承ください。

  5. 移行に関する最新情報を取得するには、Public Issue 186840968 にスターを付けます。

    Google Maps Platform サポートへのお問い合わせ

最初の解決手順

一般的なトラブルシューティングの手順については、ルート証明書ストアの更新が必要かどうかを確認する方法をご覧ください。

ルート証明書をインポートまたはエクスポートする必要がある場合は、信頼できる証明書の管理もご覧ください。

上記の方法で問題が解決しない場合は、以下の情報を準備したうえで Google Maps Platform サポートにお問い合わせください。

  1. 影響を受けているサーバーの場所
  2. サービスが呼び出している Google の IP アドレス
  3. この問題の影響を受けている API
  4. この問題が発生した正確な日時

  5. 以下のコマンドの出力

    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;
curl -vvI https://good.gtsr2.demosite.pki.goog/; \
openssl s_client -connect good.gtsr2.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr3.demosite.pki.goog/; \
openssl s_client -connect good.gtsr3.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr4.demosite.pki.goog/; \
openssl s_client -connect good.gtsr4.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 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/<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 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 トラフィックが正常に送信されていることを示しています。

*   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 の証明書はどのようになりますか？

{# disableFinding(LINE_OVER_80)}

…
---
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 仮想デバイス（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 バージョンでは、そこで信頼されている一連のルート証明書によって、デバイス自体が有効寿命を迎えた後も数年にわたってサービスが提供されます。

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

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

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

iOS: トラストストア

Apple では、信頼できるルート証明書のデフォルト セットをスマートフォン ユーザーに直接提示していません。ただし、iOS バージョン 5 以降の信頼できるルート CA は、以下の Apple サポートの記事のリンクから確認できます。

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

次の表は、上記の情報源に基づき、最も重要なルート証明書の可用性を 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 NSS 対応のアプリケーションでは、デフォルトで、システム全体の証明書データベース（通常は /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 ルート証明書ストア

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

証明書のファイル形式

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 からすべての証明書をインポートできません

一部のシステム（Java keytool など）では、PEM ファイルに複数の証明書が含まれていても、1 つの証明書しかインポートできない場合があります。初めにファイルを分割する方法については、この後の 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 Key Store の証明書を 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 プラットフォーム Standard Edition のツール リファレンス: keytool{: .external} のマニュアルをご覧ください。

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 のサンプル 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-----
…
-----END CERTIFICATE-----

このファイルには、証明書部分のみを含めることもできます。その場合、ファイルの名前（GTS_Root_R1.pem など）は、その証明書が属する CA を表しています。-----BEGIN CERTIFICATE----- トークンと -----END CERTIFICATE----- トークンの間の証明書文字列も、CA ごとに一意です。

ただし、上記のツールがない場合でも、信頼できる Google Root CA バンドル内の各証明書が適切にラベル付けされていれば、バンドルのルート CA を、信頼性の高い方法でルート証明書ストアのものと照合できます。その場合は、Issuer を使用するか、PEM ファイルの証明書文字列を比較します。

ウェブブラウザは、独自のルート証明書ストアを使用することも、オペレーションによって指定されるデフォルトのルート証明書ストアを使用することもできます。ただし、最近のブラウザであれば、信頼するルート CA のセットを管理、または少なくとも表示できます。詳しくは、質問のモバイルアプリが動作しなくなる可能性はありますか？をご覧ください。

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

付録

その他の関連情報

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

この「よくある質問」を含め、その他のドキュメントは情報が古かったり、間違っていたりする可能性があるため、信頼できる情報源として使用しないでください。ただし、Stack Exchange のさまざまな質疑応答コミュニティでは有益な情報が得られます。

また、Google Trust Services に関するよくある質問もあわせてご確認ください。

暗号、PKI、証明書、証明書チェーンの概要については、Paul Turner 氏の PKI Bootcamp YouTube プレイリストをご覧ください。

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

Android トレーニング ガイドのネットワーク セキュリティ構成では、信頼できる証明書を Android で管理する方法をさらに詳しく習得できます。

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