証明書リクエスト元がドメインを制御していることを確認したら、Public Certificate Authority CA を使用して、広く信頼されている X.509 証明書をプロビジョニングしてデプロイできます。Public CA を使用すると、主要なブラウザ、オペレーティング システム、アプリケーションで使用されるトラストストアのルートにすでに存在している TLS 証明書を、直接およびプログラムでリクエストできます。これらの TLS 証明書を使用して、インターネット トラフィックを認証して暗号化できます。
Public CA を使用すると、従来の CA ではサポートできなかった大量のユースケースを管理できます。 Google Cloud のお客様は、ドメインの TLS 証明書を Public CA から直接リクエストできます。
証明書関連の問題のほとんどは人的ミスや見落としが原因であるため、証明書のライフサイクルを自動化することをおすすめします。Public CA は、証明書の自動プロビジョニング、更新、取り消しに自動証明書管理環境（ACME）プロトコルを使用します。証明書の自動管理により、証明書の有効期限切れによるダウンタイムが短縮され、運用コストを最小限に抑えることができます。
Public CA は、App Engine、Cloud Shell、Google Kubernetes Engine、Cloud Load Balancing など、いくつかの Google Cloudサービスに TLS 証明書をプロビジョニングします。
Public CA の対象ユーザー
Public CA は、次の理由のために使用できます。
- 遍在性、拡張性、セキュリティ、信頼性に優れた TLS プロバイダをお探しの場合。
- オンプレミス ワークロードやクロスクラウド プロバイダの設定など、1 つのクラウド プロバイダからインフラストラクチャに必要な TLS 証明書が必要な場合。
- TLS 証明書の管理をインフラストラクチャ要件に合わせてカスタマイズするために、制御と柔軟性が必要な場合。
- TLS 証明書の管理を自動化したいが、GKE や Cloud Load Balancing などの Google Cloud サービスでマネージド証明書を使用できない場合。
公的に信頼されている証明書は、ビジネス要件で他のオプションを使用できない場合にのみ使用することをおすすめします。公開鍵基盤（PKI）階層の維持にかかる費用と複雑さのため、多くの企業は、プライベート階層の方が適切である場合でも、パブリック PKI 階層を使用しています。
複数のGoogle Cloud サービスにより、パブリック階層とプライベート階層の維持が大幅に簡素化されました。ユースケースに適したタイプの PKI を慎重に選択することをおすすめします。
公開証明書以外の要件については、 Google Cloud には管理が簡単な次の 2 つのソリューションが用意されています。
Anthos Service Mesh: Cloud Service Mesh には、Cloud Service Mesh 認証局（Cloud Service Mesh 認証局）を使用して GKE Enterprise で実行されているワークロード用に完全に自動化された mTLS 証明書プロビジョニングが含まれます。
Certificate Authority Service: Certificate Authority Service を使用すると、インフラストラクチャを管理することなく、カスタム プライベート CA を効率的にデプロイ、管理、保護できます。
Public CA の利点
Public CA には、次の利点があります。
自動化: インターネット ブラウザはトラフィックを完全に暗号化し、証明書の有効期間を短縮するため、期限切れの TLS 証明書を使用するリスクがあります。証明書の有効期限はウェブサイトのエラーにつながり、サービスが停止する可能性があります。Public CA は、HTTPS サーバーを設定して ACME エンドポイントから必要な TLS 証明書を自動的に取得して更新できるようにすることで、証明書の有効期限の問題を回避します。
コンプライアンス: Public CA は、セキュリティ、プライバシー、コンプライアンス管理に関する独立した機関による厳格な監査を定期的に受けています。これらの年次監査の結果として付与された Webtrust シールは、Public CA が、関連するすべての業界標準に準拠していることを示しています。
セキュリティ: Public CA のアーキテクチャと運用は、最高レベルのセキュリティ基準に従って設計されており、基盤となるインフラストラクチャのセキュリティを確認するために独立した評価を定期的に実施しています。Public CA は、Google のセキュリティに関するホワイトペーパーに記載されている管理、運用、セキュリティ対策をすべて満たすか上回っています。
Public CA のセキュリティの焦点は、複数視点のドメイン検証などの機能に拡張されています。Public CA のインフラストラクチャはグローバルに分散されています。そのため、Public CA は、地理的に多様な視点から高度な合意を必要とします。これにより、Border Gateway Protocol（BGP）ハイジャック攻撃とドメイン ネームサーバー（DNS）ハイジャック攻撃から保護できます。
信頼性: Google の実績ある技術インフラストラクチャの使用により、Public CA は可用性が高くスケーラブルなサービスとなっています。
遍在性: Google Trust Services の強力なブラウザ遍在性により、Public CA が発行する証明書を使用するサービスは、可能な限り幅広いデバイスやオペレーティング システムで動作することが保証されます。
ハイブリッド設定のための合理化された TLS ソリューション: Public CA を使用すると、さまざまなシナリオとユースケースに同じ CA を使用するカスタム TLS 証明書ソリューションを構築できます。Public CA は、ワークロードがオンプレミスまたはクロスクラウド プロバイダ環境で実行されているユースケースを効果的に提供します。
スケール: 証明書は、取得に費用がかかり、プロビジョニングと維持が困難であることがよくあります。Public CA は、大量の証明書へのアクセスを提供することで、以前は実用的でないと考えられていた方法で証明書を利用、管理できるようにします。
Certificate Manager で Public CA を使用する
Certificate Manager の Public CA 機能を使用するには、次のコンセプトについて理解している必要があります。
ACME クライアント。自動証明書管理環境（ACME）クライアントは、ACME プロトコルを使用する証明書管理クライアントです。Public CA と連携するには、ACME クライアントが外部アカウント バインディング（EAB）をサポートしている必要があります。
外部アカウント バインディング（EAB）。Certificate Manager Public CA で使用する各 ACME アカウントは、外部アカウント バインディングを使用して、対象のプロジェクトにバインドする必要があります。 Google Cloud これを行うには、対応するプロジェクトにリンクされているシークレットを使用して、各 ACME アカウントを登録する必要があります。 Google Cloud 詳細については、外部アカウント バインディングをご覧ください。
Public CA のチャレンジ
Public CA を使用して証明書をリクエストすると、Certificate Manager は、証明書に一覧表示されているドメインを制御することを証明するよう求められます。チャレンジを解決することでドメイン管理を証明できます。Public CA は、ターゲット ドメインの制御を証明した後にドメイン名を承認します。
必要な承認を取得したら、特定の期間のみ有効な証明書をリクエストできます。この期限を経過したら、3 種類のチャレンジのいずれかを解決して証明書を再度リクエストし、ドメイン名を再検証する必要があります。
本人確認の種類
Public CA は、次の種類のチャレンジをサポートします。
HTTP チャレンジ。このチャレンジには、Public CA がファイルを取得して確認できるように、HTTP サーバー（ポート 80）上の既知の場所にファイルを作成することが含まれます。詳細については、HTTP チャレンジをご覧ください。
TLS アプリケーション レイヤ プロトコル ネゴシエーション（ALPN）チャレンジ。ドメインを制御するために、ポート 443 での TLS ネゴシエーション中に特定の証明書を提供するようサーバーに要求します。詳細については、ACME TLS-ALPN チャレンジの拡張機能をご覧ください。
DNS チャレンジ。ドメインの制御を証明するために、定義された場所に特定の DNS レコードを追加する必要があります。詳細については、DNS チャレンジをご覧ください。
HTTP チャレンジまたは TLS-ALPN チャレンジを使用してドメイン名を検証する場合、クライアントは、証明書に含める検証済みドメイン名のみをリクエストできます。DNS チャレンジを使用する場合、クライアントは、証明書に含めるドメイン名のサブドメインをリクエストすることもできます。
たとえば、DNS チャレンジを使用して *.myorg.example.com を検証すると、subdomain1.myorg.example.com と subdomain2.myorg.example.com はワイルドカード証明書によって自動的にカバーされます。ただし、HTTP チャレンジまたは TLS-ALPN チャレンジを使用して myorg.example.com を検証する場合は、クライアントは証明書に myorg.example.com を含めるようにリクエストすることしかできず、DNS 以外のチャレンジを使用して *.myorg.example.com を検証することはできません。
チャレンジ ソリューションのロジック
Public CA のチャレンジ ロジックは次のとおりです。
- Public CA はランダムなトークンを提供します。
- クライアントは、明確に定義された場所でトークンを使用できるようにします。ロケーションはチャレンジによって異なります。
- クライアントは、チャレンジを準備したことを Public CA に知らせます。
- Public CA は、予想されるロケーションに存在するトークンが期待される値と一致するかどうかを確認します。
このプロセスが完了すると、ドメイン名が承認されます。クライアントは、そのドメイン名を含む証明書をリクエストできます。1 つのドメイン名につき 1 つのチャレンジのみを解決する必要があります。