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 証明書をすでに作成している場合は、この手順をスキップできます。

コンソール

グローバル SSL 証明書に関する作業は、[Certificate Manager] ページの [従来の証明書] タブで行うことができます。

Google Cloud コンソールの [従来の証明書] タブに移動します。
[従来の証明書] に移動
[SSL 証明書を作成] をクリックします。
証明書の名前と説明（省略可）を入力します。
[Google 管理の証明書を作成する] を選択します。
ドメインを追加します。
[作成] をクリックします。

gcloud

グローバル外部アプリケーションロードバランサまたは外部プロキシネットワークロードバランサのグローバル Google マネージド SSL 証明書を作成するには、gcloud compute ssl-certificates create コマンドを使用します。

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

次のように置き換えます。

CERTIFICATE_NAME: グローバル SSL 証明書の名前
DESCRIPTION: グローバル SSL 証明書の説明
DOMAIN_LIST: この証明書に使用する単一のドメイン名またはドメイン名のカンマ区切りリスト

Terraform

Google マネージド SSL 証明書を作成するには、google_compute_managed_ssl_certificate リソースを使用します。

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

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

api

Google マネージド証明書リソース sslCertificates.insert メソッドを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

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

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

コンソール

グローバル SSL 証明書のステータスは、[Certificate Manager] ページの [従来の証明書] タブで確認できます。

Google Cloud コンソールの [従来の証明書] タブに移動します。
[従来の証明書] に移動
省略可: SSL 証明書のリストをフィルタリングします。
[ステータス] 列を確認します。
詳細を表示するには、証明書名をクリックします。

gcloud

Google マネージド証明書のステータスを確認するには、gcloud compute コマンドを使用します。適切なコマンドを実行した後は、以下の点に注意してください。

マネージドステータス。
ドメインステータス。

Google マネージド SSL 証明書の一覧を表示するには、--global フラグを指定して、gcloud compute ssl-certificates list コマンドを使用します。

gcloud compute ssl-certificates list \
   --global

gcloud compute ssl-certificates describe コマンドを使用できます。CERTIFICATE_NAME は、次のように置き換えます。

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

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

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

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

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

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

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

コンソール

Google Cloud コンソールを使用してグローバル外部アプリケーションロードバランサまたは外部プロキシネットワークロードバランサを更新すると、SSL 証明書が正しいターゲットプロキシに自動的に関連付けられます。

Google Cloud コンソールの [ロードバランシング] ページに移動します。
[ロードバランシング] に移動
ロードバランサの名前をクリックします。
[編集]（）をクリックします。
[フロントエンドの構成] をクリックします。
正しいフロントエンド（HTTPS、HTTP/2、または SSL）をクリックします。
[その他の証明書] をクリックし、プルダウンリストから Google マネージド証明書を選択します。
[作成] をクリックします。

gcloud

SSL 証明書をグローバル外部アプリケーションロードバランサのターゲット HTTPS プロキシに関連付けるには、--global-ssl-certificates と --global フラグを指定して、gcloud compute target-https-proxies update コマンドを使用します。

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

SSL 証明書を外部ネットワークロードバランサのターゲット SSL プロキシに関連付けるには、gcloud compute target-ssl-proxies update コマンドを使用します。

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

次のように置き換えます。

TARGET_PROXY_NAME: ロードバランサのターゲットプロキシの名前
SSL_CERTIFICATE_LIST: SSL 証明書リソースのカンマ区切りのリスト

参照された証明書のリストに、新しい SSL 証明書と古い有効な SSL 証明書がすべて含まれていることを確認してください。gcloud compute target-ssl-proxies update コマンドは、--ssl-certificates の元の値を新しい値でオーバーライドします。

Terraform

ターゲット HTTPS プロキシを作成するには、google_compute_target_https_proxy リソースを使用します。

ターゲット SSL プロキシを作成するには、google_compute_target_ssl_proxy リソースを使用します。

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 レコードは、別のドメインを参照する 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 ドメイン検証は、Google Cloud ロードバランサの IP アドレスと照合するために、ドメインの A レコードと AAAA レコードを定期的にチェックする自動プロセスです。このプロセスでは、次の検証チェックまでの待機時間に対して自動指数バックオフが用意されています。デプロイが事前に準備されており、最初のデプロイから 1 日以上後の特定のメンテナンスの時間枠にサービスのカットオーバーが予定されている場合は、特定の時間内に実行されるドメイン検証に依存するのではなく、メンテナンスの時間枠の直前または期間中に証明書を作成あるいは再作成することをおすすめします（タイマーバックオフのため）。

DNS レコードの伝播時間

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

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

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

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

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

ステップ 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）を実装しています。

マネージド証明書内のドメインまたはサブドメインがロードバランサの IP アドレスを参照していない場合、またはロードバランサの IP とともに別の IP を参照している場合、更新処理は失敗します。更新の失敗を回避するには、すべてのドメインとサブドメインがロードバランサの IP アドレスを参照している必要があります。

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 をコントロールできます。

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 証明書を置き換えるには:

代替の Google マネージド SSL 証明書を作成するプロセスを開始します。この時点では、この証明書はまだアクティブになっていません。
ターゲットプロキシを更新して、参照された証明書のリストに、現在の SSL 証明書と代替の SSL 証明書が含まれるようにします。ターゲットプロキシの更新手順は次のとおりです。
- ターゲット HTTPS プロキシの更新
- ターゲット SSL プロキシの更新
注: トラフィックの処理を継続するには、ターゲットプロキシが現在の SSL 証明書を引き続き参照する必要があります。代替証明書のプロビジョニングを完了するには、ターゲットプロキシも代替証明書を参照するように変更する必要があります。
代替 SSL 証明書のプロビジョニングが完了するまで待ちます。プロビジョニングには 60 分ほどかかる場合があります。プロビジョニングが完了すると、証明書のステータスは ACTIVE になります。

注: Google マネージド証明書のプロビジョニングには、DNS とロードバランサの構成の変更がインターネット経由で伝播された時点から最長で 60 分かかります。最近 DNS 構成を更新した場合、変更が完全に反映されるまでにかなりの時間がかかる可能性があります。通常は数時間程度ですが、世界的な反映には最長で 72 時間かかることもあります。DNS の伝播の詳細については、変更の伝播をご覧ください。
すべての Google Front Ends（GFE）が代替証明書を利用できるように、さらに 30 分間待ちます。
ターゲットプロキシを更新して、参照する証明書のリストから代替 SSL 証明書を削除します。ターゲットプロキシの更新手順は次のとおりです。
- ターゲット HTTPS プロキシの更新
- ターゲット SSL プロキシの更新
10 分待って、ロードバランサが古い SSL 証明書ではなく新しい SSL 証明書を使用していることを確認します。
ターゲットプロキシを再度更新し、古い SSL 証明書リソースを削除します。ターゲットプロキシによって参照されていない SSL 証明書リソースは削除できます。

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

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

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

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

SSL 証明書を削除する

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

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

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

コンソール

グローバル SSL 証明書は、[Certificate Manager] ページの [従来の証明書] タブで削除できます。

Google Cloud コンソールの [従来の証明書] タブに移動します。
[従来の証明書] に移動
削除する SSL 証明書を選択します。
[削除] をクリックします。
もう一度 [削除] をクリックして確定します。

gcloud

グローバル SSL 証明書（グローバル外部アプリケーションロードバランサまたは外部プロキシネットワークロードバランサの場合）を削除するには、gcloud compute ssl-certificates delete コマンドと --global コマンドを使用します。

gcloud compute ssl-certificates delete CERTIFICATE_NAME \
    --global

次のように置き換えます。

CERTIFICATE_NAME: SSL 証明書の名前

次のステップ

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

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

始める前に

権限

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

コンソール

gcloud

Terraform

api

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

コンソール

gcloud

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

コンソール

gcloud

Terraform

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

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

DNS レコードの伝播時間

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

追加手順

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

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

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

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

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

SSL 証明書を削除する

コンソール

gcloud

次のステップ

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

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