このページは Cloud Translation API によって翻訳されました。

SSL 証明書のトラブルシューティング

トラブルシューティングの手順は、使用しているSSL 証明書の種類によって異なります。

Google マネージド証明書のトラブルシューティング

Google マネージド証明書の場合、次の 2 つのステータスがあります。

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

マネージドステータス

証明書のステータスを確認するには、次のコマンドを実行します。

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

マネージドステータスの値は次のとおりです。

マネージドステータス	説明
`PROVISIONING`	Google マネージド証明書が作成され、 Google Cloud は認証局と連携して証明書に署名します。 Google マネージド証明書のプロビジョニングには、DNS とロードバランサの構成の変更がインターネットを経由して伝播された時点から最長で 60 分かかります。最近 DNS 構成を更新した場合、変更が完全に反映されるまでにかなりの時間がかかる可能性があります。通常は数時間程度ですが、世界的な反映には最長で 72 時間かかることもあります。DNS の伝播の詳細については、変更の伝播をご覧ください。証明書が `PROVISIONING` 状態のままである場合は、正しい証明書がターゲットプロキシに関連付けられていることを確認してください。これを確認するには、`gcloud compute target-https-proxies describe` コマンドまたは `gcloud compute target-ssl-proxies describe` コマンドを実行します。
`ACTIVE`	Google マネージド SSL 証明書が認証局から取得されます。ロードバランサで使用できるまでに、さらに 30 分かかる可能性があります。
`PROVISIONING_FAILED`	証明書が実際に `ACTIVE` である場合でも、簡単に `PROVISIONING_FAILED` を確認できる場合があります。ステータスを再確認してください。ステータスが `PROVISIONING_FAILED` のままの場合、Google マネージド証明書は作成されましたが、認証局は署名できません。Google マネージド SSL 証明書の使用のすべての手順を完了していることを確認してください。 Google Cloud プロビジョニングが成功するかステータスが `PROVISIONING_FAILED_PERMANENTLY` に変わるまで、再試行します。
`PROVISIONING_FAILED_PERMANENTLY`	Google マネージド証明書は作成されましたが、認証局は DNS またはロードバランサの構成の問題により署名できません。この状態では、 Google Cloud はプロビジョニングを再試行しません。 Google マネージド SSL 証明書の置き換えを作成し、置き換え用の証明書がロードバランサのターゲットプロキシに関連付けられていることを確認してください。 Google マネージド SSL 証明書の使用のすべてのステップを確認または完了します。その後、完全にプロビジョニングに失敗した証明書を削除できます。
`RENEWAL_FAILED`	ロードバランサまたは DNS 構成に問題があるため、Google マネージド証明書を更新できませんでした。マネージド証明書内のドメインまたはサブドメインが A/AAAA レコードを使用してロードバランサの IP アドレスを参照していない場合、更新処理は失敗します。既存の証明書は引き続き利用できますが、まもなく期限切れとなります。構成を確認してください。ステータスが `RENEWAL_FAILED` のままの場合は、新しい証明書をプロビジョニングし、新しい証明書の使用に切り替えて、前の証明書を削除します。証明書の更新の詳細については、Google マネージド SSL 証明書の更新をご覧ください。

ドメインステータス

ドメインのステータスを確認するには、次のコマンドを実行します。

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

この表では、ドメインステータスの値について説明します。

ドメインステータス	説明
`PROVISIONING`	ドメインに対して Google マネージド証明書が作成されます。 Google Cloud は認証局と連携して証明書に署名します。
`ACTIVE`	ドメインは、証明書をプロビジョニングするために正常に検証されました。SSL 証明書が複数のドメイン用である場合は、すべてのドメインが `ACTIVE` ステータスで、証明書のマネージドステータスも `ACTIVE` である場合にのみ、証明書をプロビジョニングできます。
`FAILED_NOT_VISIBLE`	ドメインの証明書のプロビジョニングが完了していません。次のいずれかが問題である可能性があります。ドメインの DNS レコードが、 Google Cloud ロードバランサの IP アドレスに解決されません。この問題を解決するには、DNS の A レコードと AAAA レコードを更新して、ロードバランサの IP アドレスを指定します。 DNS は、ロードバランサの IP アドレス以外の IP アドレスに解決されないようにする必要があります。たとえば、A レコードが正しいロードバランサに解決され、AAAA は別のロードバランサに解決される場合、ドメインのステータスは `FAILED_NOT_VISIBLE` になります。更新された DNS A レコードと AAAA レコードが完全に伝播されるまで、かなり時間がかかることがあります。通常は数時間程度ですが、インターネットを介した反映には最長で 72 時間かかることもあります。ドメインステータスは、伝播が完了するまで `FAILED_NOT_VISIBLE` になります。 SSL 証明書がロードバランサのターゲットプロキシに適用されていません。この問題を解決するには、ロードバランサの構成を更新してください。グローバル転送ルール用のフロントエンドポートに、SSL プロキシを使用する外部プロキシネットワークロードバランサ用のポート 443 が含まれていません。この問題は、ポート 443 を使用して新しい転送ルールを追加すると解決できます。 Certificate Manager の証明書マップがターゲットプロキシに適用されます。適用された証明書マップが優先され、直接適用された証明書は無視されます。この問題は、プロキシから証明書マップを切断することで解決できます。マネージドステータスが `PROVISIONING` の場合、ドメインステータスが `FAILED_NOT_VISIBLE` であっても、 Google Cloud はプロビジョニングを再試行します。
`FAILED_CAA_CHECKING`	ドメインの CAA レコードの構成の問題により、証明書のプロビジョニングに失敗しました。正しい手順で行っていることを確認します。
`FAILED_CAA_FORBIDDEN`	ドメインの CAA レコードが、 Google Cloud 使用する必要がある CA を指定していないため、証明書のプロビジョニングに失敗しました。正しい手順で行っていることを確認します。
`FAILED_RATE_LIMITED`	認証局にレート制限付きの証明書署名リクエストがあるため、証明書のプロビジョニングに失敗しました。新しい証明書のプロビジョニング、新しい証明書の使用への切り替え、前の証明書の削除が可能です。また、Google Cloud サポートに連絡することもできます。

マネージド証明書の更新

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

マルチパースペクティブドメイン検証

Google Cloud は、Google マネージド証明書を定期的に更新し、認証局（CA）から証明書をリクエストします。Google Cloud が証明書の更新に使用する CA は、マルチパースペクティブ発行確認（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 がロードバランサに接続する必要はありません。

セルフマネージド SSL 証明書のトラブルシューティング

このガイドでは、セルフマネージド SSL 証明書の構成に関する問題のトラブルシューティングについて説明します。

証明書を解析できない

Google Cloud には、PEM 形式の証明書が必要です。証明書が PEM 形式の場合は、次の点を確認してください。

次の OpenSSL コマンドを使用して証明書を検証します。CERTIFICATE_FILE は、証明書ファイルのパスで置き換えます。

openssl x509 -in CERTIFICATE_FILE -text -noout

OpenSSL が証明書を解析できない場合:

CA にお問い合わせください。
新しい秘密鍵と証明書を作成します。

共通名またはサブジェクト代替名がない

Google Cloud では、証明書に共通名（CN）またはサブジェクト代替名（SAN）属性のどちらかを設定する必要があります。詳細については、CSR を作成するをご覧ください。

どちらの属性も設定されていない場合にセルフマネージド証明書を作成しようとすると、次のようなエラーメッセージが表示されます。 Google Cloud

ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch resource:
 -   The SSL certificate is missing a Common Name(CN) or Subject Alternative
   Name(SAN).

秘密鍵を解析できない

Google Cloud には、秘密鍵の基準を満たす PEM 形式の秘密鍵が必要です。

次の OpenSSL コマンドで秘密鍵を検証します。PRIVATE_KEY_FILE は秘密鍵のパスで置き換えます。

    openssl rsa -in PRIVATE_KEY_FILE -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

この問題を解決するには、新しい秘密鍵と証明書を作成する必要があります。

パスフレーズを含む秘密鍵

OpenSSL でパスフレーズが求められた場合、秘密鍵からパスフレーズを削除してから、 Google Cloudで使用する必要があります。次の OpenSSL コマンドを使用できます。

openssl rsa -in PRIVATE_KEY_FILE \
    -out REPLACEMENT_PRIVATE_KEY_FILE

プレースホルダを有効な値に置き換えます。

PRIVATE_KEY_FILE: パスフレーズで保護されている秘密鍵のパス
REPLACEMENT_PRIVATE_KEY_FILE: 書式なしテキストの秘密鍵のコピーを保存するパス。

有効期限が近い中間証明書

サーバー（リーフ）証明書の前に中間証明書が期限切れになった場合、CA がベストプラクティスに従っていない可能性があります。

中間証明書が期限切れになると、Google Cloud で使用されるリーフ証明書が無効になることがあります。これは、次のように SSL クライアントによって異なります。

一部の SSL クライアントは、リーフ証明書の有効期限のみを確認し、期限切れの中間証明書を無視します。
一部の SSL クライアントは、期限切れの中間証明書を持つチェーンを無効として扱い、警告を表示します。

この問題を解決するには:

CA が新しい中間証明書に切り替わるのを待ちます。
新しい証明書をリクエストします。
新しい鍵で新しい証明書を再度アップロードします。

CA が中間証明書に対するクロス署名を許可している場合もあります。CA に確認してください。

RSA 公開指数が大きすぎる

次のエラーメッセージは、RSA 公開指数が 65537 より大きい場合に表示されます。RFC 4871 で指定されているように、必ず 65537 を使用してください。

ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch resource:
 -   The RSA public exponent is too large.

target-proxy から SSL 証明書を削除する

次の手順で、ターゲット https プロキシに適用されている単一の SSL 証明書を削除する方法を示します。

target-https-proxy を一時ファイルにエクスポートします。

gcloud compute target-https-proxies export TARGET_PROXY_NAME > /tmp/proxy

/tmp/proxy ファイルを編集して次の行を削除します。

sslCertificates:
-   https://www.googleapis.com/compute/v1/projects/...

/tmp/proxy ファイルをインポートします。

gcloud compute target-https-proxies import TARGET_PROXY_NAME \
   --source=/tmp/proxy

省略可: SSL 証明書を削除します。

gcloud compute ssl-certificates delete SSL_CERT_NAME

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

TARGET_PROXY_NAME: ターゲット HTTPS プロキシリソースの名前。
SSL_CERT_NAME: SSL 証明書の名前。