SSL 証明書の作成と使用

HTTPS または SSL 負荷分散を使用するには、少なくとも 1 つの SSL 証明書をロードバランサのターゲット プロキシに関連付ける必要があります。ターゲット プロキシの構成には最大 15 個の SSL 証明書を設定できます。SSL 証明書ごとに、まず SSL 証明書リソースを作成します。SSL 証明書リソースには SSL 証明書情報が含まれています。

SSL 証明書は、ご自分で取得および管理する証明書(セルフマネージド証明書)、Google が取得および管理する証明書(Google マネージド証明書のいずれかです。

SSL 証明書リソースは、ターゲット HTTPS プロキシおよびターゲット SSL プロキシのロードバランサでのみ使用されます。SSL 証明書リソースをいつどのように使用するかについては、ドキュメントをご覧ください。

SAN 証明書は HTTPS 負荷分散に対応しています。

複数の SSL 証明書を使用する

最大 15 個の SSL 証明書を使用して、HTTPS や SSL プロキシのロードバランサのターゲット プロキシを構成できます。セルフマネージド SSL 証明書と Google マネージド SSL 証明書を任意に組み合わせることができます。同じロードバランサの IP アドレスとポートを使用して複数のドメインからサービスを提供し、ドメインごとに異なる SSL 証明書を使用する場合は、複数の SSL 証明書を使用します。Google Cloud Platform は、この目的のために、RFC 6066 で定義されているように、Server Name Indication(SNI)を実装しています。

SSL 証明書は、ターゲット HTTPS プロキシ(TargetHttpsProxy)とターゲット SSL プロキシ(TargetSslProxy)リソースで使用されます。これらのリソースごとに最低 1 つ以上の SSL 証明書を指定する必要があります。最大で 15 個までの SSL 証明書を指定できます。複数の証明書を指定した場合、SSL 証明書のリストの最初の証明書が、ロードバランサに関連付けられたプライマリ SSL 証明書と見なされます。

クライアントがリクエストを送信すると、ロードバランサはクライアントが指定した SNI ホスト名を使用して、クライアント SSL 接続のネゴシエーションに使用する証明書を選択します。可能な限り、ロードバランサは、クライアントが指定した SNI ホスト名と共通名(CN)またはサブジェクト代替名(SAN)が一致し、デジタル署名に RSA または ECDSA を使用するクライアントの機能と互換性のある証明書を選択します。使用可能な証明書のいずれも選択できない場合、またはクライアントが SNI ホスト名を指定していない場合、ロードバランサはリスト内の最初の証明書であるプライマリ証明書を使用して SSL をネゴシエートします。

複数の SSL 証明書(クリックで拡大)
複数の SSL 証明書(クリックで拡大)

共通名のワイルドカード

セルフマネージド SSL 証明書では、共通名にワイルドカードを使用できます。たとえば、共通名が *.example.com. である証明書は、ホスト名 www.example.com および foo.example.com と一致しますが、a.b.example.comexample.com とは一致しません。ロードバランサが証明書を選択するときは、ワイルドカードを使用した証明書よりもワイルドカードを使用しない証明書とのホスト名の一致を常に優先します。

f*.example.com のようなワイルドカード フラグメントを使用した証明書はサポートされていません。

Google マネージド SSL 証明書は、ワイルドカードの使用をサポートしていません。

複数の SSL 証明書の例

次に、複数の SSL 証明書が HTTPS 負荷分散でどのように機能するかの例を示します。この例では、3 つのホスト名と 3 つの SSL 証明書があることを前提としています。

複数の SSL 証明書が HTTPS 負荷分散で機能する仕組み(クリックで拡大)
複数の SSL 証明書が HTTPS 負荷分散で機能する仕組み(クリックで拡大)

ホスト名は次のとおりです。

  • www.example.com
  • www.example.org
  • www.example.net

IP アドレス 203.0.113.1 の HTTPS ロードバランサを使用して、www.example.com、www.example.org、www.example.net からコンテンツを提供しています。ロードバランサが www.example.com に cert-1 を、www.example.org に cert-2 を、www.example.net に cert-3 を使用するように SSL 証明書を設定します。また、クライアントが SNI を使用しない場合、またはクライアント提供のサーバー名が使用可能な証明書と一致しない場合は、ロードバランサが cert-1 を使用するように設定します。証明書が一致しない場合に使用されるよう指定する証明書は、フォールバック証明書です。

SSL 証明書は cert-1、cert-2、cert-3 です。SSL 証明書 cert-1 がプライマリ証明書です。証明書を作成するときに、それぞれの証明書をホスト名に関連付けます。この例では、結果は次のようになります。

  • cert-1:www.example.com
  • cert-2:www.example.org
  • cert-3:www.example.net

クライアントが SNI を使用し、TLS(SSL)handshake 中にホスト名を提供した場合、ロードバランサはそのホスト名に関連付けられた証明書を使用します。たとえば、上記の図に示すように、user-2 のクライアントが TLS handshake 中に SNI ホスト名として www.example.org を指定すると、ロードバランサは cert-2 を提供します。ユーザーのクライアントが SNI ホスト名を指定しない場合、またはロードバランサの証明書と一致しないホスト名を指定する場合、ロードバランサはプライマリ証明書 cert-1 を使用します。

クライアントが SNI に対応していないときにプライマリ証明書をフォールバックとして使用する場合、またはクライアントが提供したサーバー名が使用可能などの証明書とも一致しない場合は、一般にフォールバックが発生した時点でクライアントから証明書検証エラーが報告されます。この動作のほうがサーバー側で handshake に失敗する動作よりも、デバッグが容易になるため好ましいと言えます。ただし、ユーザーは証明書の警告を無視できますが、意図的にフォールバック証明書を使用してリクエストを処理することはセキュリティ上よいプラクティスとは言えません。

セルフマネージド SSL 証明書と Google マネージド SSL 証明書

次の 2 種類の SSL 証明書を使用できます。

  • セルフマネージド SSL 証明書。ご自分で取得、プロビジョニング、更新する証明書です。

  • Google マネージド SSL 証明書。お客様のドメイン用に Google Cloud Platform が取得して管理する証明書です。自動的に更新されます。

Google マネージド SSL 証明書はドメイン認証(DV)証明書のみで、証明書に関連付けられている組織や個人は特定されません。セルフマネージド証明書は、ドメイン認証(DV)、実在認証(または組織認証)(OV)、拡張認証(EV)証明書のいずれかです。ドメイン認証、組織認証、拡張認証型の証明書について詳しくは、公開鍵証明書をご覧ください。

Google マネージド SSL 証明書は、証明書ごとに 1 つのドメイン名のみをサポートします。ワイルドカード共通名や複数のサブジェクトの代替名を複数使用することはサポートされていません。

Google マネージド SSL 証明書とセルフマネージド SSL 証明書を 1 つのターゲット プロキシで組み合わせて使用することができ、任意の順序で設定できます。

Google マネージド証明書は、Cloud CDN を有効または無効にして使用できます。

セルフマネージド SSL 証明書を作成、使用する

このセクションでは、たいていの Linux、BSD、Mac OS X システムに付属の openssl コマンドライン プログラムを使用して、秘密鍵と公開鍵、および証明書署名リクエスト(CSR)を生成します。

秘密鍵と署名済み証明書を取得する

暗号化されていない秘密鍵と、その鍵を使用して生成された証明書が必要です。すでに秘密鍵と証明書を認証局から取得している場合は、SSL 証明書リソースを作成するに進んでください。まだ取得していない場合は、新しい秘密鍵を作成して自己署名証明書を生成し、それを使用して SSL 証明書リソースを作成できます。

新しい秘密鍵を作成するには、最初に鍵と証明書を格納する新しいフォルダを作成し、次に openssl を使用して鍵を生成します。コマンドのオプションについては、openssl-genrsa の man ページをご覧ください。

$ mkdir ssl_cert
$ cd ssl_cert
$ openssl genrsa -out example.key 2048

この例では、RSA-2048 暗号化を使用しています。現在サポートされているのは、RSA-2048 暗号化と ECDSA P-256 暗号化のみです。

署名済み証明書を生成するには、CSR が必要になります。次のコマンドを実行して作成します。コマンドのオプションについては、openssl-req の man ページをご覧ください。

$ openssl req -new -key example.key -out example.csr

この新しい CSR を使用して、有効な証明書を認証局から取得します。自己署名証明書を生成するには、次のコマンドを実行します。コマンドのオプションについては、openssl-x509 の man ページをご覧ください。

$ openssl x509 -req -days 365 -in example.csr -signkey example.key -out example.crt

既存の証明書ファイルから SSL 証明書リソースを作成する

既存の証明書ファイルから SSL 証明書リソースを作成するには、Google Cloud Platform Console または gcloud コマンドを実行します。証明書リソースを作成するには、証明書を作成済みである必要があります。

Google Cloud Platform では、証明書チェーンにあるすべての証明書の PEM エンコーディングが有効かどうかのみを検証します。チェーンが正しく構築されているかどうかの検証は行いません。有効な証明書チェーンを作成することは、お客様の責任です。

複数の SSL 証明書を使用してロードバランサを構成する場合は、証明書ごとに SSL 証明書リソースを作成してください。

Console


Google Cloud Platform Console では、HTTPS または SSL プロキシのロードバランサのフロントエンドを作成または編集するときに、新しい SSL 証明書リソースを作成します。

フロントエンドに対する新しい SSL 証明書リソースを作成するには、次の手順を行います。

  1. Google Cloud Platform Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. HTTPS プロキシまたは SSL プロキシのロードバランサの名前をクリックします。
  3. [編集] 鉛筆アイコンをクリックします。
  4. [フロントエンドの設定] をクリックします。
    1. 既存のフロントエンドの場合、編集を行うフロントエンドの横の [編集] 鉛筆アイコンをクリックしてください。[証明書] プルダウン メニューで、表示されている証明書を選択し、[新しい証明書の作成] をクリックします。
    2. 新しいフロントエンドの場合、[証明書] プルダウン メニューで [証明書を選択してください] をクリックし、[新しい証明書の作成] をクリックします。
  5. [新しい証明書の作成] ダイアログ ボックスで証明書リソースの [名前] を入力し、必要に応じて [説明を追加] をクリックして説明を入力します。
  6. [証明書をアップロードする] を選択します。
  7. [公開鍵証明書] フィールドで、[アップロード] をクリックして .crt ファイルをアップロードするか、.key ファイルの内容全体(内容を -----BEGIN CERTIFICATE----------END CERTIFICATE----- で囲む)をフィールドに貼り付けます。
  8. [証明書チェーン] フィールドで、[アップロード] をクリックして .csr ファイルをアップロードするか、.csr ファイルの内容全体(内容を -----BEGIN CERTIFICATE REQUEST----------END CERTIFICATE REQUEST----- で囲む)をフィールドに貼り付けます。
  9. [秘密鍵証明書] フィールドで、[アップロード] をクリックして以前に生成した.key ファイルを使用して秘密鍵をアップロードします。このファイルの内容は、たとえば、-----BEGIN RSA PRIVATE KEY----------END RSA PRIVATE KEY----- で囲まれています。
  10. [作成] をクリックします。
  11. 追加の証明書を作成するには、[追加の証明書] をクリックしてから、[証明書を選択してください] をクリックし、[新しい証明書の作成] をクリックします。上の手順に従って、該当するファイルをアップロードするか、その内容をフィールドに貼り付けます。

gcloud


gcloud コマンドライン ツールで SSL 証明書を作成するには、次のコマンドを実行します。

gcloud compute ssl-certificates create [SSL_CERTIFICATE] \
    --certificate [CRT_FILE_PATH] \
    --private-key [KEY_FILE_PATH]
  • [SSL_CERTIFICATE]: 証明書リソースに付ける名前。

  • [CRT_FILE_PATH]: 証明書ファイル(.crt ファイル)のパス名とファイル名。

  • [KEY_FILE_PATH]: キーファイル(.key ファイル)のパス名とファイル名。

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

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

Google マネージド SSL 証明書は、お客様のドメイン用に Google Cloud Platform が取得および管理する証明書です。証明書ごとに 1 つのホスト名をサポートするドメイン認証(DV)証明書です。詳しくは、SSL 証明書のタイプをご覧ください。

マネージド SSL 証明書を GKE で使用することもできます。この実装方法の詳細は、Google マネージド SSL 証明書の使用をご覧ください。

Google マネージド SSL 証明書を使用してロードバランサを設定する

gcloud コマンドライン ツールで Google マネージド SSL 証明書を使用してロードバランサを作成する一般的な流れは次のとおりです。これらのステップのほとんどは Google Cloud Platform サイトで実行しますが、ステップ 5 はドメイン登録事業者のサイトで行う必要があります。

  1. Google マネージド SSL 証明書リソースの作成の手順に沿って、ご自分のドメイン用の Google マネージド SSL 証明書リソースを作成します。
  2. HTTPS または SSL プロキシ ロードバランサを作成します。HTTPS ロードバランサを作成する手順については、HTTP(S) 負荷分散の設定および HTTP(S) ロードバランサの作成をご覧ください。SSL プロキシ ロードバランサを作成する手順については、Google Cloud Load Balancing 用の SSL プロキシの設定をご覧ください。
  3. Google マネージド SSL 証明書リソースを参照するターゲット HTTPS プロキシまたはターゲット SSL プロキシを作成します。ターゲット プロキシの詳細については、ターゲット プロキシまたは Google Cloud Load Balancing 用の SSL プロキシの設定をご覧ください。ターゲット プロキシを作成する際に、作成した Google マネージド SSL 証明書リソースを参照します。
  4. ターゲット プロキシへの転送ルールをポート 443 上に 1 つまたは複数作成します。転送ルールの詳細については、転送ルールのコンセプトをご覧ください。
  5. (DNS レコードを管理している )ドメイン登録事業者のサイト、DNS ホスト、または ISP で、ドメインの DNS レコードを追加または更新し、作成した転送ルールに関連付けられている IP アドレスを参照するように設定します。
  6. 次の CAA(Certification Authority Authorization)レコードを追加し、ドメイン用の証明書の発行が許可されている認証局を指定します。
    your_domain. CAA 0 issue "letsencrypt.org"
    your_domain. CAA 0 issue "pki.goog"
    
  7. SSL 証明書リソースが ACTIVE ステータスになるのを待ちます。詳細については、Google マネージド SSL 証明書リソースのステータスをご覧ください。

Google Cloud Platform Console を使用してロードバランサを作成する際に、Google マネージド SSL 証明書を作成することもできます。

Google マネージド証明書を発行しリソースの状態を ACTIVE にするには、ロードバランサを設定しておく必要があります。それには、証明書リソースを参照するターゲット プロキシと転送ルール、ドメインのホスト名を転送ルールの IP アドレスに解決する DNS 構成が含まれます。詳しくは、Google マネージド SSL 証明書リソースのステータスをご覧ください。

ロードバランサに使用する SSL 証明書をセルフマネージドから Google マネージドに移行する

ロードバランサに使用する SSL 証明書をセルフマネージドから Google マネージド証明書に移行する場合、Google マネージド SSL 証明書が ACTIVE になるまでセルフマネージド SSL 証明書を削除しないでください。Google マネージド SSL 証明書は正常にプロビジョニングされると自動的に ACTIVE になります。Google マネージド SSL 証明書が ACTIVE になったら、セルフ マネージド SSL 証明書を削除できます。

以下の手順でセルフ マネージド SSL 証明書から Google マネージド SSL 証明書に移行します。

  1. Google マネージド証明書リソースを作成します。
  2. Google マネージド証明書リソースを適切なターゲット プロキシに関連付けます。その際に、既存のセルフマネージド証明書リソースはそのターゲット プロキシのリストに残しておきます。
  3. Google マネージド SSL 証明書リソースのステータスが ACTIVE になるまで待ちます。
  4. ステータスが ACTIVE になったら、ターゲット プロキシの設定を更新して証明書のリストからセルフマネージド証明書リソースを除外します。

Google マネージド SSL 証明書の更新

Google マネージド SSL 証明書は、有効期限が切れる前に自動的に更新されます。更新プロセスの詳細については、Google が管理する SSL 証明書リソースのステータスをご覧ください。

Google マネージド SSL 証明書リソースを作成する

Console


Google Cloud Platform Console では、HTTPS または SSL プロキシ ロードバランサのフロントエンドを作成または編集するときに、新しい SSL 証明書リソースを作成します。

フロントエンド用の新しい SSL 証明書リソースを作成するには、次の手順を行います。

  1. Google Cloud Platform Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. HTTPS プロキシまたは SSL プロキシ ロードバランサの名前をクリックします。
  3. [編集] 鉛筆アイコンをクリックします。
  4. [フロントエンドの設定] をクリックします。
    1. 既存のフロントエンドの場合、編集を行うフロントエンドの横の [編集] 鉛筆アイコンをクリックしてください。[証明書] プルダウン メニューで、表示されている証明書を選択し、[新しい証明書の作成] をクリックします。
    2. 新しいフロントエンドの場合、[証明書] プルダウン メニューで [証明書を選択してください] をクリックし、[新しい証明書の作成] をクリックします。
  5. [新しい証明書の作成] ダイアログ ボックスで証明書リソースの [名前] を入力し、必要に応じて [説明を追加] をクリックしてから説明を入力します。
  6. [Google 管理の証明書を作成する] を選択します。
  7. 正しい [ドメイン] を入力します。
  8. [作成] をクリックします。
  9. 追加の証明書を作成するには、[追加の証明書] をクリックしてから、[証明書を選択してください] をクリックし、[新しい証明書の作成] をクリックします。上の手順に従って、該当するファイルをアップロードするか、その内容をフィールドに貼り付けます。

gcloud


次の gcloud コマンドを使用して、Google マネージド SSL 証明書リソースを作成します。

gcloud beta compute ssl-certificates create [SSL_CERTIFICATE_NAME] \
    --domains [DOMAIN] --description [DESCRIPTION]

Google マネージド SSL 証明書をターゲット プロキシに関連付ける

ターゲット プロキシに SSL 証明書リソースを関連付ける手順に沿って、ターゲット プロキシに Google マネージド SSL 証明書リソースを関連付けます。この手順は、セルフマネージド SSL 証明書と Google マネージド SSL 証明書の両方に該当します。

Google マネージド SSL 証明書リソースのステータス

このセクションでは SSL 証明書リソースの status について説明します。これは、証明書のプロビジョニング問題のモニタリングや解決のために利用できるフィールドです。

Google マネージド SSL 証明書リソースの status フィールドの値は、プロビジョニングの際に変更され、プロビジョニングや更新の際のエラーを示します。

status フィールドの値を調べるには、次のコマンドを使用します。

gcloud beta compute ssl-certificates list

次のような出力が表示されます。

NAME               TYPE          CREATION_TIMESTAMP             EXPIRE_TIME              MANAGED_STATUS
managed-cert       MANAGED       2018-08-10T08:44:30.220-07:00  2018-11-08T06:50:19.000-08:00  ACTIVE
    example.com: ACTIVE
self-managed-cer  SELF_MANAGED  2018-03-08T05:11:20.170-08:00  2019-03-08T02:15:21.000-08:00

ここで、ステータス PROVISIONING は、Google マネージド証明書リソースは作成済みでプロビジョニングはまだ完了していないことを示しています。

証明書のプロビジョニング処理を続行するには、次のすべての条件を満たす必要があります。

  • ドメインの DNS レコードがロードバランサのターゲット プロキシの IP アドレスを参照している。

  • ターゲット プロキシが Google マネージド証明書リソースを参照している。

  • ロードバランサの構成(転送ルールの作成など)が完了している。

正しく構成されていれば、証明書のプロビジョニングの合計所要時間は 30~60 分程度になります。

上記の構成手順のいずれかが正しく行われていなければ、Google マネージド証明書リソースの最終ステータスは PROVISIONING_FAILED になります。

設定が正しくても DNS レコードが伝播するのに時間がかかるため、PROVISIONING_FAILED になる場合があります。PROVISIONING_FAILED というステータスが表示された場合は、設定をもう一度確認してからシステムが再試行するのを待ちます。その後にステータスをもう一度確認します。なお、DNS 障害が発生した場合には、domainStatus フィールドを調べて障害ドメインを確認できます。

PROVISIONING_FAILED_PERMANENTLY は、DNS または負荷分散の構成の問題により証明書のプロビジョニングが失敗したことを示すステータスです。プロビジョニングの処理は再試行されません。

プロビジョニング処理が失敗して PROVISIONING_FAILED_PERMANENTLY というステータスになった場合は、ロードバランサの構成を確認して問題を修正します。それから SSL 証明書リソースを作成し直します。次に示すように、通常の手順に従ってください。

  1. 新しい証明書リソースを作成します。
  2. 新しい証明書リソースをターゲット プロキシに追加します。
  3. ターゲット プロキシを更新し、古い証明書リソースをリストから除外します。
  4. 古い証明書リソースを削除します。

RENEWAL_FAILED は、DNS または負荷分散の構成に問題があるため証明書の更新が失敗したことを示すステータスです。既存の証明書は引き続き利用できますが、まもなく期限切れとなります。構成に問題がないことを確認した後もステータスが RENEWAL_FAILED から変わらない場合は、新しい証明書をプロビジョニングし、新しい証明書の使用に切り替えてから、古い証明書を削除します。

ACTIVE は、SSL 証明書が認証局から取得され、Google マネージド証明書リソースのプロビジョニングが完了し、ロードバランサが証明書を使用していることを示すステータスです。

Google マネージド SSL 証明書リソースのドメイン ステータス

このセクションでは、domainStatus フィールドに指定できる値と、プロビジョニングに関する問題の対処方法について説明します。

status フィールドの値を調べるには、次のコマンドを使用します。

gcloud beta compute ssl-certificates list

次のような出力が表示されます。

NAME               TYPE          CREATION_TIMESTAMP             EXPIRE_TIME              MANAGED_STATUS
managed-cert       MANAGED       2018-08-10T08:44:30.220-07:00  2018-11-08T06:50:19.000-08:00  ACTIVE
    example.com: ACTIVE
self-managed-cer  SELF_MANAGED  2018-03-08T05:11:20.170-08:00  2019-03-08T02:15:21.000-08:00

Google マネージド SSL 証明書リソースの domainStatus フィールドには、Google マネージド SSL 証明書リソースのドメイン リクエストのステータスが含まれます。このセクションでは、このフィールドに入る値について説明します。

PROVISIONING は、ドメインの証明書のプロビジョニングが進行中で、証明書がアクティブになるまで 30~60 分かかることを示すステータスです。

FAILED_NOT_VISIBLE は、DNS または負荷分散の構成に問題があるため、ドメインの証明書のプロビジョニングが失敗したことを示すステータスです。証明書のドメインがロードバランサの IP アドレスに解決されるように DNS が構成されていることを確認します。

FAILED_CAA_CHECKING は、ドメインの CAA レコードのチェックに失敗したことを示すステータスです。

FAILED_CAA_FORBIDDEN は、証明書の発行がドメインの明示的な CAA レコードによって禁止されていることを示すステータスです。

CAA レコードによって証明書を発行できる認証局が制限されている場合は、CAA レコードから制限を削除してください。

FAILED_RATE_LIMITED は、Google マネージド SSL 証明書に適用されている上限に達したことを示すステータスです。このステータスは、認証局がトラフィックをレート制限するために生じます。Google に短期間に多数の証明書リクエストが行われた場合、お客様に一時的にレート制限が課されることがあります。このエラーが表示された場合は、サポートにお問い合わせのうえ、上限の引き上げについてご相談ください。

ACTIVE は、Google マネージド SSL 証明書がプロビジョニングされており、このドメインに問題がないことを示すステータスです。システムに反映されるまで 30~60 分かかることがあります。ステータスが ACTIVE の間だけでなく、ロードバランサにリクエストを送信したときに証明書を表示できたら、プロビジョニングされた証明書は完全に有効な状態です。

SSL 証明書リソースのプロパティを表示する

SSL 証明書リソースに関する情報を表示するには、次のコマンドを実行します。

gcloud beta compute ssl-certificates describe [SSL_CERTIFICATE]
  • [SSL_CERTIFICATE]: SSL 証明書リソースの名前。

SSL 証明書リソースを一覧表示する

すべての SSL 証明書リソースをリスト形式で表示するには、次のコマンドを実行します。

gcloud beta compute ssl-certificates list

このコマンドの出力では、セルフマネージド SSL 証明書と Google マネージド SSL 証明書の区別が表示されます。出力の表示のうち MANAGED は、Google マネージド証明書であることを示しています。

NAME               TYPE          CREATION_TIMESTAMP             EXPIRE_TIME              MANAGED_STATUS
managed-cert       MANAGED       2018-08-10T08:44:30.220-07:00  2018-11-08T06:50:19.000-08:00  ACTIVE
    example.com: ACTIVE
self-managed-cer  SELF_MANAGED  2018-03-08T05:11:20.170-08:00  2019-03-08T02:15:21.000-08:00

SSL 証明書リソースをターゲット プロキシに関連付ける

Google Cloud Platform Console または gcloud コマンドを使用して、1~15 個の SSL 証明書をターゲット プロキシに関連付けることができます。SSL 証明書がセルフマネージドか Google マネージドかは関係ありません。

Google Cloud Platform Console でロードバランサを作成する場合、SSL 証明書をアップロードすると自動的に正しいターゲット プロキシに関連付けられます。新しいロードバランサを作成するには、次のドキュメントの手順を行います。

ターゲット HTTPS プロキシまたはターゲット SSL プロキシに関連付けられた証明書を更新するには、まず新しい SSL 証明書リソースを作成し、Google Cloud Platform Console または適切な gcloud コマンドを使用してターゲット プロキシを更新します。

既存の SSL 証明書を新しい証明書リソースに置き換える場合は、新しい SSL 証明書リソースを作成してターゲット プロキシに関連付け、SSL 証明書リソースの削除の手順を行って古い証明書リソースを削除します。

Console


  1. Google Cloud Platform Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. ロードバランサの名前をクリックします。
  3. [編集] 鉛筆アイコンをクリックします。
  4. [フロントエンドの設定] をクリックします。
  5. 正しいフロントエンドをクリックします。
  6. [その他の証明書] をクリックし、次にプルダウン リストから証明書を選択するか、[証明書を追加] をクリックして既存の証明書を選択するか、または [新しい証明書の作成] をクリックします。
  7. [新しい証明書の作成] を選択した場合は、独自の証明書をアップロードするか、Google マネージド証明書を作成します。
  8. [作成] をクリックします。

gcloud


ターゲット HTTPS プロキシの場合、次のコマンドを使用します。最大 15 個の SSL 証明書リソースを指定できます。

gcloud compute target-https-proxies update [PROXY_NAME] \
    --ssl-certificates [SSL_CERT_1][,[SSL_CERT_2],...]
  • [PROXY_NAME]: 更新する target-https-proxies リソースの名前。
  • [[SSL_CERT_1][,[SSL_CERT_2],...]: SslCertificate リソースの名前のリスト(最大 15 個)。

ターゲット SSL プロキシの場合、次のコマンドを使用します。最大 15 個の SSL 証明書リソースを指定できます。

gcloud compute target-ssl-proxies update  [PROXY_NAME] \
    --ssl-certificates [SSL_CERT_1][,[SSL_CERT_2],...]
  • [PROXY_NAME]: 更新する target-ssl-proxies リソースの名前。
  • [SSL_CERT_1][,[SSL_CERT_2],...]: SslCertificate リソースの名前のリスト(最大 15 個)。

SSL 証明書リソースを削除する

1 つまたは複数の SSL 証明書リソースを削除するには:

Console


  1. [HTTP(S) ロードバランサの編集] ページの左パネルで、[フロントエンドの設定] をクリックします。
  2. 右パネルで、削除する証明書リソースの横にある [X] をクリックします。
  3. [完了] をクリックします。

gcloud


gcloud compute ssl-certificates delete [SSL_CERT_1][,[SSL_CERT_2],...]
  • [SSL_CERTIFICATE]: 削除する SslCertificate リソースの名前。

制限事項

  • HTTPS または SSL プロキシ ロードバランサには、少なくとも 1 つの SSL 証明書が必要です。セルフマネージド証明書と Google マネージド証明書を合わせて最大 15 個の SSL 証明書を関連付けることができます。

  • Google マネージド証明書に指定できるドメインは 1 つのみです。

  • Google マネージド証明書を SSL プロキシの負荷分散に使用する場合、Google マネージド証明書のプロビジョニングと更新を行うには、トラフィックのフロントエンド ポートを 443 に設定する必要があります。

  • サポートされているドメイン名の最大長は 64 バイトです。

  • 証明書を発行できる認証局を制限する CAA レコードは設定しないでください。その場合、Google マネージド証明書が発行されなくなる可能性があります。

トラブルシューティング

SSL 証明書をアップロードする際のエラー メッセージ

SSL 証明書をアップロードしようとすると、次のエラー メッセージが表示されることがあります。

The SSL certificate could not be parsed.

Google Cloud Platform では、PEM 形式の証明書が必要です。証明書が PEM 形式でない場合、無効になる可能性があります。

証明書を検証するには、Linux コマンドラインまたは Cloud Shell で次のコマンドを実行します。

    openssl x509 -in certificate.crt -text -noout

次のレスポンスが表示された場合、証明書は無効です。

  • unable to load certificate
  • Expecting: TRUSTED CERTIFICATE

無効なファイルが自己生成証明書からのものである場合は、秘密鍵と署名付き証明書を取得するの手順を使用して、新しい証明書を生成できます。認証局(CA)から提供された証明書の場合は、その CA に問い合わせてください。

SSL 鍵をアップロードする際のエラー メッセージ

SSL 鍵をアップロードしようとすると、次のエラー メッセージが表示されることがあります。

The SSL key could not be parsed.

キーに関する詳細情報を入手するには、次のコマンドを実行します。

    openssl rsa -in privateKey.pem -check

次のレスポンスが表示された場合、そのキーは無効です。

  • unable to load Private Key
  • Expecting: ANY PRIVATE KEY
  • RSA key error: n does not equal p q
  • RSA key error: d e not congruent to 1
  • RSA key error: dmp1 not congruent to d
  • RSA key error: dmq1 not congruent to d
  • RSA key error: iqmp not inverse of q

これらの回答が表示された場合は、秘密鍵と署名済み証明書の取得の手順に従ってください。

無効な鍵が暗号化された場合、次のレスポンスが表示されます。

  • Enter pass phrase for privateKey.pem

Google Cloud Platform では、この鍵を暗号化されていない形式でアップロードする必要があります。鍵を復号するには、次のコマンドを実行し、プロンプトが表示されたらパスワードを入力します。コマンドのオプションについては、openssl-rsa の man ページをご覧ください。

    openssl rsa -in privateKey.pem -out privateKeyUnencrypted.pem

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...