Google マネージド SSL 証明書を使用する

このページでは、Compute Engine Google マネージド SSL 証明書を作成および使用する方法について説明します。

Certificate Manager を使用して Google マネージド証明書を作成するには、デプロイの概要をご覧ください。

Google マネージド SSL 証明書は、ドメイン用にGoogle Cloud が取得して管理するドメイン検証（DV）証明書です。1 つの証明書で複数のホスト名をサポートしており、Google は証明書を自動的に更新します。

Google マネージド証明書は、次のロードバランサでサポートされています。

• グローバル外部アプリケーション ロードバランサ
• 従来のアプリケーション ロードバランサ
• 外部プロキシ ネットワーク ロードバランサ（ターゲット SSL プロキシを使用）

Compute Engine の Google マネージド SSL 証明書は、リージョン外部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサではサポートされていません。これらのロードバランサでは、Compute Engine セルフマネージド SSL 証明書を使用するか、代わりに Certificate Manager の使用を検討してください。

Google Kubernetes Engine でマネージド SSL 証明書を使用することもできます。詳細については、Google マネージド SSL 証明書の使用をご覧ください。

ロードバランサの作成前、作成中、作成後に、Google マネージド証明書を作成できます。このページでは、ロードバランサの作成中ではなく、作成前または作成後に Compute Engine 証明書を作成することを前提としています。ロードバランサの作成中に証明書を作成するには、ロードバランサの入門ページをご覧ください。

始める前に

• SSL 証明書の概要を十分に理解します。
• Google マネージド SSL 証明書に使用するドメイン名があることを確認します。Cloud Domains を使用している場合は、ドメインの登録をご覧ください。

• プロジェクトで Compute Engine API が有効になっていることを確認します。

  Compute Engine API を有効にする

権限

このガイドに記載された手順を行う前に、プロジェクトで SSL 証明書を作成および変更できる権限が必要です。次のいずれかに該当する場合は、この操作を行うことができます。

• プロジェクトのオーナーまたは編集者（roles/owner または roles/editor）である。
• プロジェクトに Compute セキュリティ管理者ロール（compute.securityAdmin）と Compute ネットワーク管理者ロール（compute.networkAdmin）の両方がある。
• プロジェクトで割り当てられているカスタムロールに、compute.sslCertificates.* 権限と、compute.targetHttpsProxies.* または compute.targetSslProxies.* のいずれか、あるいはその両方（使用するロードバランサによる）が含まれている。

ステップ 1.Google マネージド SSL 証明書を作成する

ロードバランサの作成前、作成中、作成後に、Google マネージド証明書を作成できます。Google Cloud コンソールでロードバランサを作成するときに、 Google Cloud コンソールを使用して証明書を作成できます。また、ロードバランサの作成前または作成後に証明書を作成することもできます。このステップでは、後で 1 つ以上のロードバランサに追加できる証明書の作成方法について説明します。

Google マネージド SSL 証明書をすでに作成している場合は、この手順をスキップできます。

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --description=DESCRIPTION \
    --domains=DOMAIN_LIST \
    --global

resource "google_compute_managed_ssl_certificate" "lb_default" {
  provider = google-beta
  name     = "myservice-ssl-cert"

  managed {
    domains = ["example.com"]
  }
}

POST https://compute.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/global/sslCertificates
{
  "name": "ssl-certificate-name",
  "managed": {
    "domains": [
      "www.example.com"
    ]
  },
  "type": "MANAGED"
}

Google マネージド SSL 証明書のステータスを確認する

gcloud compute ssl-certificates list \
   --global

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
   --global \
   --format="get(name,managed.status, managed.domainStatus)"

この時点で、証明書のステータスとドメインのステータスは PROVISIONING です。このページの手順を完了すると、ステータスが ACTIVE に変わります。

ステータスの詳細については、トラブルシューティング ページをご覧ください。

ステップ 2: ロードバランサを作成または更新する

ACTIVE にするには、Google マネージド SSL 証明書をロードバランサ、特にロードバランサのターゲット プロキシに関連付ける必要があります。

作成した SSL 証明書が PROVISIONING 状態になったら、ロードバランサの作成で使用できます。手順については、次の入門ガイドをご覧ください。

• Compute Engine バックエンドを使用してグローバル外部アプリケーション ロードバランサを設定する
• Compute Engine バックエンドを使用して従来のアプリケーション ロードバランサを設定する
• SSL プロキシを使用して外部プロキシ ネットワーク ロードバランサを設定する

ここで説明するように、既存のロードバランサの更新に使用することもできます。

gcloud compute target-https-proxies update TARGET_PROXY_NAME \
    --ssl-certificates SSL_CERTIFICATE_LIST \
    --global-ssl-certificates \
    --global

gcloud compute target-ssl-proxies update TARGET_PROXY_NAME \
    --ssl-certificates SSL_CERTIFICATE_LIST

resource "google_compute_target_https_proxy" "lb_default" {
  provider = google-beta
  name     = "myservice-https-proxy"
  url_map  = google_compute_url_map.lb_default.id
  ssl_certificates = [
    google_compute_managed_ssl_certificate.lb_default.name
  ]
  depends_on = [
    google_compute_managed_ssl_certificate.lb_default
  ]
}

それぞれのターゲット HTTPS プロキシまたはターゲット SSL プロキシは、1 つ以上の SSL 証明書を参照している必要があります。ターゲット プロキシは、複数の SSL 証明書を参照できます。詳細については、ロード バランシングのリソースの割り当てと上限のターゲット プールとターゲット プロキシをご覧ください。

ステップ 3: ターゲット プロキシの関連付けを確認する

ロードバランサを作成または更新した後、SSL 証明書がロードバランサのターゲット プロキシに関連付けられていることを確認できます。

ターゲット プロキシの名前がわからない場合は、gcloud compute target-https-proxies list と gcloud compute target-ssl-proxies list コマンドを使用して、プロジェクト内のターゲット プロキシを一覧表示します。

次のコマンドを実行して、SSL 証明書とターゲット プロキシ間の関連付けを確認します。

グローバル外部アプリケーション ロードバランサの場合:

gcloud compute target-https-proxies describe TARGET_HTTPS_PROXY_NAME \
    --global \
    --format="get(sslCertificates)"

外部プロキシ ネットワーク ロードバランサの場合:

gcloud compute target-ssl-proxies describe TARGET_SSL_PROXY_NAME \
    --format="get(sslCertificates)"

この時点では、Google マネージド証明書のステータスは PROVISIONING のままである可能性があります。 Google Cloud は認証局と連携して証明書を発行します。Google マネージド証明書のプロビジョニングには最長で 60 分かかります。

ステップ 4: ロードバランサの IP アドレスを参照するように DNS A および AAAA レコードを更新する

DNS レコードが登録事業者のサイト、DNS ホスト、または ISP で管理されている可能性があります。

レコードを管理する際は、次の点に注意してください。

• ドメインとサブドメインの DNS A レコード（IPv4 の場合）と DNS AAAA レコード（IPv6 の場合）が、ロードバランサの転送ルールまたはルールと関連付けられた IP アドレスを参照していることを確認してください。

  SSL 証明書をプロビジョニングするには、A レコードと AAAA レコードがパブリック DNS でロードバランサの IP アドレスを参照するようにします。

• Cloud DNS を使用している場合は、ドメインを設定して、ネームサーバーを更新します。

• Google マネージド証明書に複数のドメインがある場合は、すべてのドメインとサブドメインの DNS レコードを追加または更新して、ロードバランサの IP アドレスを参照します。Google マネージド証明書のドメインとサブドメインが、ロードバランサの転送ルールの IP アドレスとは別の IP を指している場合、証明書の検証は失敗します。

• DNS プロバイダがすべてのグローバル ドメイン検証リクエストに一貫して応答していることを確認します。

次の条件に該当する場合は、マネージド証明書は正常にプロビジョニングされます。

• ドメインの DNS レコードは、別のドメインを参照する CNAME レコードを使用しています。
• もう一方のドメインには、ロードバランサの IP アドレスを参照する A または AAAA レコードが含まれています。

dig コマンドを実行すると、設定を確認できます。たとえばドメインが www.example.com の場合は、dig コマンドを実行します。

dig www.example.com

; <<>> DiG 9.10.6 <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31748
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.example.com.           IN  A

;; ANSWER SECTION:
www.example.com. 1742    IN      CNAME   example.net.
example.net.      12     IN      A       34.95.64.10

;; Query time: 43 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jun 03 16:54:44 PDT 2020
;; MSG SIZE  rcvd: 193

この例では、34.95.64.10 はロードバランサの IP アドレスです。

インターネット上の DNS リゾルバは、Google Cloudの管理外です。有効期間（TTL）に従ってリソース レコード セットがキャッシュに保存されるため、dig コマンドまたは nslookup コマンドを実行すると、キャッシュに保存された値が返されることがあります。Cloud DNS を使用している場合は、変更の伝播をご覧ください。

DNS レコードの伝播時間

更新された DNS A レコードと AAAA レコードが完全に伝播されるまで、かなり時間がかかることがあります。通常は数時間程度ですが、インターネットを介した反映には最長で 72 時間かかることもあります。

次のコマンドを再実行します。

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
    --format="get(managed.domainStatus)"

ドメインのステータスが FAILED_NOT_VISIBLE の場合は、伝播が完了していない可能性があります。

詳細については、トラブルシューティング ページで Google マネージド SSL 証明書のドメイン ステータスの説明をご覧ください。

多視点ドメイン検証

Google Cloud は、認証局（CA）から Google マネージド証明書をリクエストして、定期的に更新します。Google Cloud が証明書の更新に使用する CA には、Multi-Perspective Issuance Corroboration（MPIC）と呼ばれる多視点ドメイン検証方法が使用されます。このプロセスの一環として、認証局はドメインの DNS 設定を確認し、ドメインの IP アドレスの背後にあるサーバーに接続しようとすることで、ドメインの制御を確認します。これらの検証は、インターネット上の複数の観察ポイントから行われます。検証プロセスが失敗すると、Google マネージド証明書は更新されません。その結果、ロードバランサは期限切れの証明書をクライアントに提供し、ブラウザ ユーザーには証明書エラー、API クライアントには接続エラーが発生します。

DNS レコードの構成ミスで多視点ドメイン検証に失敗しないようにするには、次の点に注意してください。

• ドメインとサブドメインの DNS A レコード（IPv4）と DNS AAAA（IPv6）レコードは、ロードバランサの転送ルールに関連付けられた IP アドレスのみを参照します。レコードに他のアドレスが存在すると、検証が失敗する可能性があります。
• DNS レコードの検証を行う CA は、複数のロケーションから DNS レコードをクエリします。DNS プロバイダが、すべてのグローバル ドメイン検証リクエストに一貫して応答していることを確認します。
• GeoDNS（リクエストのロケーションに基づいて異なる IP アドレスを返す）またはロケーションベースの DNS ポリシーを使用すると、レスポンスの不整合が生じ、検証が失敗する可能性があります。DNS プロバイダが GeoDNS を使用している場合は、GeoDNS を無効にするか、すべてのリージョンで同じロードバランサの IP アドレスが返されるようにします。
• DNS 構成でロードバランサの IP アドレスを明示的に指定する必要があります。CDN などの中間レイヤが原因で、予期しない動作が発生する可能性があります。IP アドレスには、リクエストパスにリダイレクト、ファイアウォール、CDN を介さずに直接アクセスできる必要があります。詳細については、このドキュメントの CDN の背後にあるロードバランサをご覧ください。
• 任意の DNS グローバル反映チェッカーを使用して、関連するすべての DNS レコードが世界中で正しく、一貫して解決されているのを確認することをおすすめします。

構成の変更を確認する

DNS レコードを構成したら、新しい証明書を作成して、既存の証明書とともにロードバランサに接続することで、レコードが正しいことを確認できます。この手順では、CA で証明書のプロビジョニング チェックを強制的に即時実行し、数分以内に構成の変更を確認できます。これを行わないと、既存の証明書の自動更新に数日から数週間かかるため、設定に不確実性が生じます。

証明書のステータスが ACTIVE になれば、証明書が発行されたことを示しています。これにより、DNS 構成が正しいことを確認できます。この時点で、同じドメインに 2 つの別々の証明書が存在しないように、以前の証明書を削除することをおすすめします。このプロセスによって、ロードバランサへのトラフィックが中断されることはありません。

新しい証明書は検証ツールとして機能します。この証明書の作成によって、MPIC を使用した多視点ドメイン検証がその設定で正しく機能していることを確認できます。

CDN の背後にあるロードバランサ

CDN が有効になっているロードバランサの場合、リクエストパスの一部のサードパーティ CDN プロバイダが検証リクエストをブロックすることがあります。このエラーは、CDN プロバイダが HTTP(S) トラフィックをアクティブにプロキシしている場合に発生します。

このような場合は、証明書を Certificate Manager に移行し、DNS 認証方法を使用して Google マネージド証明書をプロビジョニングすることをおすすめします。後者のアプローチでは、CA がロードバランサに接続する必要はありません。

ステップ 5: OpenSSL でテストする

証明書とドメインのステータスがアクティブになった後、ロードバランサが Google マネージド SSL 証明書の使用を開始するまでに 30 分ほどかかる場合があります。

テストするには、次の OpenSSL コマンドを実行します。DOMAIN は DNS 名に置き換え、IP_ADDRESS はロードバランサの IP アドレスに置き換えます。

echo | openssl s_client -showcerts -servername DOMAIN -connect IP_ADDRESS:443 -verify 99 -verify_return_error

このコマンドは、ロードバランサがクライアントに提示する証明書を出力します。他の詳細情報とともに、出力に証明書チェーンと Verify return code: 0 (ok) が含まれていることを確認します。

追加手順

このセクションでは、証明書を管理するための追加手順を説明します。

Google マネージド SSL 証明書を使用して複数のドメインをサポートする

複数のサブジェクトの代替名がサポートされています。それぞれの Google マネージド SSL 証明書は、Google マネージド SSL 証明書あたりの最大ドメイン数までサポートします。

ドメイン数が上限を超えている場合、複数の Google マネージド証明書をリクエストする必要があります。たとえば、（最大 + 1）個のドメインで Google マネージド証明書を作成しようとしても、Google は証明書を発行しません。代わりに、2 つ以上の Google マネージド証明書を作成し、各証明書に関連付けられるドメインを明示する必要があります。

Google Cloud は、RFC 6066 で定義されているように、Server Name Indication（SNI）を実装しています。

証明書が更新プロセスのドメイン検証ステップで失敗しないようにするには、DNS A レコードと AAAA レコードの要件を確認してください。

Google マネージド SSL 証明書を更新する

Google Cloud は、90 日間有効なマネージド証明書をプロビジョニングします。有効期限が切れる約 1 か月前に、証明書の更新プロセスが自動的に開始されます。このために、ドメインの Certification Authority Authorization（CAA）DNS レコードと CA のリストの両方にある認証局（CA）が選択されます。

更新に使用する CA は、以前のバージョンの Google マネージド証明書を発行するときに使用した CA とは異なる場合があります。ドメインの CAA DNS レコードで、Google マネージド証明書が使用する CA のリストから 1 つの CA を確実に指定することにより、Google Cloud が更新に使用する CA をコントロールできます。

証明書が更新プロセスのドメイン検証ステップで失敗しないようにするには、DNS A レコードと AAAA レコードの要件を確認してください。

Google マネージド証明書を発行できる CA を指定する

DNS ソフトウェアでは、Google マネージド証明書の発行を許可する CA を明示的に承認することをおすすめします。すべてのシナリオでそうする必要はありませんが、特定の状況では必要になります。

たとえば、外部 DNS サービスを使用していて、Google マネージド証明書が取り消された場合、そのサービスでは 1 つ以上の特定の CA が発行した新しい証明書のみを検証できます。

これを行うには、CAA レコードを作成または変更して、pki.goog または letsencrypt.org、あるいはその両方を含めます。CAA レコードがない場合、デフォルトでは、pki.goog と letsencrypt.org の両方が許可されます。

DOMAIN. CAA 0 issue "pki.goog"
DOMAIN. CAA 0 issue "letsencrypt.org"

letsencrypt.org 証明書のサポートはベストエフォート方式で提供されます。最高の信頼性を得るには、pki.goog と letsencrypt.org の両方を許可します。CA を 1 つだけ指定した場合、その CA のみが証明書の作成と更新に使用されます。この方法はおすすめしません。

証明書を初めて作成するとき、 Google Cloud は pki.goog または letsencrypt.org を選択し、それを使用して証明書を発行します。Google が証明書を更新するときは、CAA レコード（作成した場合）で指定した CA に応じて、他の CA が証明書を発行する場合があります。次のいずれかの場合、別の CA によって証明書が更新される場合があります。

• ドメインの DNS CAA レコードがない。
• DNS CAA レコードに両方の CA が含まれている。

詳しくは、RFC の CAA DNS レコードをご覧ください。

letsencrypt.org が国際化ドメイン名（IDN）を発行する。pki.goog は現在 IDN をサポートしていません。

Cloud DNS を使用している場合は、レコードの追加方法を確認して、--type フラグを CAA に設定してください。

既存の SSL 証明書を置き換える

既存の SSL 証明書を置き換えるには:

1. 代替の Google マネージド SSL 証明書を作成するプロセスを開始します。この時点では、この証明書はまだアクティブになっていません。

2. ターゲット プロキシを更新して、参照された証明書のリストに、現在の SSL 証明書と代替の SSL 証明書が含まれるようにします。ターゲット プロキシの更新手順は次のとおりです。

   • ターゲット HTTPS プロキシの更新
   • ターゲット SSL プロキシの更新

3. 代替 SSL 証明書のプロビジョニングが完了するまで待ちます。プロビジョニングには 60 分ほどかかる場合があります。プロビジョニングが完了すると、証明書のステータスは ACTIVE になります。

4. すべての Google Front Ends（GFE）が代替証明書を利用できるように、さらに 30 分間待ちます。

5. ターゲット プロキシを更新して、参照する証明書のリストから代替 SSL 証明書を削除します。ターゲット プロキシの更新手順は次のとおりです。

   • ターゲット HTTPS プロキシの更新
   • ターゲット SSL プロキシの更新

6. 10 分待って、ロードバランサが古い SSL 証明書ではなく新しい SSL 証明書を使用していることを確認します。

7. ターゲット プロキシを再度更新し、古い SSL 証明書リソースを削除します。ターゲット プロキシによって参照されていない SSL 証明書リソースは削除できます。

古い SSL 証明書を削除しない場合、この証明書は有効期限が切れるまでアクティブのままになります。

セルフ マネージド SSL 証明書から Google マネージド SSL 証明書に移行する

ロードバランサをセルフ マネージド SSL 証明書から Google マネージド SSL 証明書に移行する場合、次の手順をこの順序どおりに行う必要があります。

1. 新しい Google マネージド証明書を作成します。
2. 既存のセルフ マネージド証明書とターゲット プロキシの関連付けを保ちながら、新しい Google マネージド証明書と正しいターゲット プロキシを関連付けます。
3. Google マネージド証明書のステータスが ACTIVE になるまで待ちます。
4. 新しい証明書が Google Front End（GFE）に配信されるまで 30 分待ちます。
5. ターゲット プロキシを再度更新し、セルフ マネージド リソースを削除します。ターゲット プロキシによって参照されていないセルフ マネージド SSL 証明書リソースは削除できます。

SSL 証明書を削除する

SSL 証明書を削除する前に、HTTPS または SSL ターゲット プロキシがこの証明書を参照していないことを確認してください。作成する方法は次の 2 つです。

• この証明書を参照するターゲット プロキシを削除します。

• この証明書を参照するターゲット プロキシを更新して、それを除外します。手順は次のとおりです。

  • HTTPS ターゲット プロキシを更新します。
  • SSL ターゲット プロキシを更新します。

1 つ以上の SSL 証明書を削除するには:

gcloud compute ssl-certificates delete CERTIFICATE_NAME \
    --global

次のステップ

• SSL 証明書のトラブルシューティングを行う。SSL 証明書のトラブルシューティングをご覧ください。
• Terraform スクリプトを使用して Google マネージド証明書を作成する。Cloud Run の例（外部アプリケーション ロードバランサの Terraform モジュールの例）をご覧ください。