このページは Cloud Translation API によって翻訳されました。

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

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

用語
全般情報
トラブルシューティング
信頼できる証明書の管理
付録

現在 Google が進めているルート CA の移行プロセスについて詳しくは、移行の影響をご覧ください。

用語

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

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

全般情報

移行の影響

概要

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

第 1 段階の後、Google Maps Platform サービスの TLS セキュリティは、GS Root R2 によって保証されるようになりました。GS Root R2 は、非常に認知度が高く、幅広く信頼されているルート認証局（CA）です。Google は、自社発行の Google Trust Services（GTS）のルート CA への移行を円滑化するため、この認証局を GMO GlobalSign から買い取りました。

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

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

GTS ルート CA は、最新のオペレーティングシステムと TLS クライアントライブラリの大部分からすでに信頼されていますが、従来のシステムのほとんどで移行を円滑化するために、Google は、GlobalSign Root CA R1（実績と信頼性でトップクラスのルート CA）を使用するクロス署名を、GMO GlobalSign から買い取りました。

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

これは、2018 年の移行の第 1 段階で対応していただいたお客様にも当てはまります。つまり、その時点で Google の指示に沿って、Google の信頼できるルート CA バンドルをすべてインストールしていただいたお客様です。

次の場合は、システムをご確認いただく必要があります。

非標準または従来型のプラットフォームでサービスが実行されているか、独自のルート証明書ストアを管理している
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 に移行します。つまり、Google のサービスは、この新しい CA によって発行される TLS リーフ証明書に徐々に移行していきます。

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

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

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

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

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

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

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

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

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

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

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

はい。ルート CA の移行は、Google のすべてのサービスと API が対象となります（実際の移行スケジュールはサービスによって異なります）。ただし、Google Maps Platform クライアントアプリケーションで使用されるルート証明書ストアに、信頼できる Google Root CA バンドルの CA がすべて含まれていることを確認できた場合、現在進行中の移行によってサービスに影響が及ぶことはないと考えられます。また、両者を同期させることで、今後のルート CA の変更にも対処できます。

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

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

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

以下のテストエンドポイントを使用してアプリケーション環境をテストします。

GTS Root R1 Cross テストエンドポイントへの TLS 接続を確立できるのであれば、GS Root R2 の有効期限切れの影響はありません。
GTS Root R1 テストエンドポイントへの TLS 接続を確立できるのであれば、GTS Root R1 Cross と GlobalSign Root CA - R1 の有効期限切れ（2028 年）がアプリケーションに影響を及ぼす可能性は低いと言えます。

次の場合であれば、システムは通常、このルート 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 の入手方法をご覧ください。

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

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

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

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; \
curl -vvI --cacert roots.pem https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Google Root CA の移行はいつ、どのように実施されますか？

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

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

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

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

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

まず、1 つのデータセンターでのみ運用を開始します。
その後、他のデータセンターにも段階的に展開し、最終的にはすべてのデータセンターに適用します。
いずれかの段階で重大な問題が検出された場合は、テストを一時的にロールバックして、その問題に対処します。
状況を確認しながら、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 など）に対応できるようにする必要があります。

その他の要件については、GTS に関するよくある質問の TLS クライアントを Google と通信させる場合の推奨要件は何ですか？をご覧ください。

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

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

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

メンテナンスが継続され、定期的に更新が行われているメインストリームの OS（Ubuntu、Red Hat、Windows 10、Server 2019、OS X など）を使用している場合は、デフォルトのルート証明書ストアに GTS Root R1 証明書が含まれているはずです。

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

エンドユーザーデバイスから 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 Root CA バンドルと同期させるべきなのはなぜですか？

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

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

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

今後のルート 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 ルート証明書は、ほとんどの最新のブラウザによってすでに認識、信頼されています。また、GMO 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 Root R1 などの Google の新しい GTS ルート CA がすでにサポートされている可能性が非常に高くなります。また、従来型のシステムも、今後数年間 Google 発行の証明書へのクロス署名に使用される GlobalSign Root CA - R1 をサポートしている可能性が非常に高くなります。

ただし、サードパーティの証明書追加スケジュールは Google の管理下にないため、次善の方法として、システムアップデートを定期的に適用することをおすすめします。

たとえば、サードパーティの Mozilla は、CA 証明書プログラムとして、証明書の追加スケジュールを公開しています。

トラブルシューティング

必要なツールはどこで入手できますか？

curl の入手方法

OS ディストリビューションが curl を提供しない場合は、https://curl.haxx.se/ からダウンロードできます。ソースをダウンロードし、このツールをご自身でコンパイルするか、（お使いのプラットフォーム用に用意されている場合は）コンパイル済みのバイナリをダウンロードします。

OpenSSL の入手方法

ご利用の OS で openssl が提供されていない場合は、https://www.openssl.org/ からソースをダウンロードして、このツールをコンパイルできます。サードパーティによってビルドされたバイナリのリストは、https://www.openssl.org/community/binaries.html でご確認ください。ただし、これらのビルドは OpenSSL チームがサポートしているものでも、推奨しているものでもありません。

Wireshark、Tshark、Tcpdump の入手方法

ほとんどの Linux ディストリビューションには、wireshark や、そのコマンドラインツールの tshark、tcpdump が含まれていますが、他の OS 用の最初の 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 バンドルから、アプリケーションで使用するルート証明書ストアに、必要なルート証明書をインストールします。

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

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

最初の解決手順

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

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

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

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

以下のコマンドの出力

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

必要なツールの入手方法については、必要なツールをどこで入手できますか？をご覧ください。

サポートケースの提出

Google Maps Platform のサポートとリソースにあるサポートケースの作成の手順に従ってください。

サポートケースを提出する際は、最初の解決手順に記載されているデータに加え、以下の情報もお知らせください。

公開 IP アドレス
DNS サーバーの公開 IP アドレス
https://maps.googleapis.com/ で発生した TLS ネゴシエーションエラーの tcpdump または Wireshark によるパケットキャプチャ（可能な場合）。スナップショットサイズが十分に大きい PCAP フォーマットを使用し、切り捨てずにパケット全体をキャプチャしてください（古いバージョンの tcpdump で -s0 を使用するなど）
可能であれば、TLS 接続エラーの原因を示すサービスログの抜粋（できれば、完全なサーバー証明書チェーン情報）

必要なツールの入手方法については、必要なツールをどこで入手できますか？をご覧ください。

公開イシュー 186840968 への投稿

公開イシュー 186840968 にコメントを投稿するときは、最初の解決手順に示されている情報を記載してください。

DNS の公開アドレスを確認するには、どうすればよいですか？

Linux では、次のコマンドを実行します。

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

Windows では、nslookup をインタラクティブモードで実行します。

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

curl 出力の見方

-vvI フラグを指定して curl を実行すると、多くの有益な情報が得られます。出力の見方は次のとおりです。

「*」で始まる行には、TLS ネゴシエーションの出力と接続終了情報が表示されます。
「>」で始まる行には、curl が送信した HTTP リクエストが表示されます。
「<」で始まる行には、サーバーから返された HTTP レスポンスが表示されます。
プロトコルが HTTPS の場合、「>」または「<」の行は TLS 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 の証明書はどのようになりますか？

…
---
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 バージョンごとに示しています。これは、現在、Android Virtual Device（AVD）で提供されているシステムイメージを使用し、手動で検証したものです。システムイメージがない場合は、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 のマニュアルをご覧ください。

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 のさまざまな質疑応答コミュニティ、AdamW on Linux and more サイト、confirm blog などでは有益な情報が得られます。

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

証明書のピニングなど、高度な機能について詳しくは、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 ベンダーが提供するリポジトリをご覧ください。

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

用語

全般情報

移行の影響

概要

技術面の概要

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

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

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

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

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

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

Google Root CA バンドルの検証

Google Root CA の移行はいつ、どのように実施されますか？

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

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

注意事項

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

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

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

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

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

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

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

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

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

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

ブラウザやオペレーティング システムに、Google Trust Services のルート証明書がいつ追加されますか？

トラブルシューティング

必要なツールはどこで入手できますか？

curl の入手方法

OpenSSL の入手方法

Wireshark、Tshark、Tcpdump の入手方法

Java keytool の入手方法

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

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

最初の解決手順

サポートケースの提出

公開イシュー 186840968 への投稿

DNS の公開アドレスを確認するには、どうすればよいですか？

curl 出力の見方

使用された TLS ライブラリとルート証明書バンドル

ユーザー エージェント

TLS handshake に失敗した場合

TLS handshake に成功した場合

取得したサーバー証明書を人が判読できる形式で出力する方法

OpenSSL では、クロス署名された Google の証明書はどのようになりますか？

信頼できる証明書の管理

信頼できるルート証明書をスマートフォンで確認するには、どうすればよいですか？

Android: 信頼できる証明書

iOS: トラストストア

システムのルート証明書ストアはどこにありますか？更新するにはどうすればよいですか？

OpenSSL ルート証明書ストア

Java ルート証明書ストア

Mozilla NSS ルート証明書ストア

Microsoft .NET ルート証明書ストア

証明書のファイル形式

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

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

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

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

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

roots.pem から証明書を個別に取得するには、どうすればよいですか？

PEM ファイルと、自分のシステムでサポートされている形式間での変換方法

PEM ファイルを DER 形式に変換するには、どうすればよいですか？

PEM ファイルを PKCS #7 に変換するには、どうすればよいですか？

PEM ファイルを PKCS #12（PFX）に変換するには、どうすればよいですか？

ルート証明書ストアの証明書を一覧表示、出力、エクスポートする

Java Key Store の証明書を PEM ファイルとしてエクスポートするには、どうすればよいですか？

NSS ルート証明書ストアから証明書を PEM ファイルとしてエクスポートするには、どうすればよいですか？

人が判読できる形式で PEM 証明書を出力する方法

OpenSSL を使用して証明書ファイルを出力

Java keytool を使用して証明書を出力

ルート証明書ストアにインストールされている証明書を確認するには、どうすればよいですか？

付録

その他の関連情報

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

ブラウザやオペレーティングシステムに、Google Trust Services のルート証明書がいつ追加されますか？

ユーザーエージェント