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

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

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

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

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

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

リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサでは、Google マネージド SSL 証明書がサポートされません。これらのロードバランサでは、セルフ マネージド SSL 証明書を使用してください

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

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

始める前に

権限

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

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

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

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

コンソール

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

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

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] ページの [従来の証明書] タブで確認できます。

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

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 証明書が正しいターゲット プロキシに自動的に関連付けられます。

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

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 listgcloud 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 アドレスを参照していることを確認してください。

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

  • Google マネージド証明書に複数のドメインがある場合は、すべてのドメインとサブドメインの DNS レコードを追加または更新して、ロードバランサの 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 レコードの伝播時間

更新された 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 アドレスを参照している必要があります。

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

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

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

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

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

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

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

letsencrypt.org 証明書のサポートはベストエフォート方式で提供されます。最高の信頼性を得るには、pki.googletsencrypt.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 証明書が含まれるようにします。ターゲット プロキシの更新手順は次のとおりです。

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

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

  5. ターゲット プロキシを更新して、参照する証明書のリストから代替 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 つです。

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

コンソール

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

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

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 モジュールの例)をご覧ください。