Certificate Manager のトラブルシューティング

このページでは、Certificate Manager の使用時に発生する可能性のある最も一般的なエラーについて説明します。また、これらのエラーを診断して解決する手順も説明します。

TLS（SSL）証明書に関連する問題の解決については、SSL 証明書のトラブルシューティングをご覧ください。

Certificate Manager の証明書に関連するエラー

このセクションでは、Google マネージド Certificate Manager 証明書の authorizationAttemptInfo フィールドに関連するエラーのトラブルシューティング情報について説明します。エラーは、次のフィールドに次の値が設定されている場合にのみ、managed.authorizationAttemptInfo.troubleshooting セクションに表示されます。

  • managed.authorizationAttemptInfo.state = FAILED
  • managed.authorizationAttemptInfo.failureReason = CONFIG

エラーとその解決方法の詳細については、次の表をご覧ください。

エラー 説明
CNAME_MISMATCH このエラーは、想定される CNAME レコードの値が解決された CNAME レコードの値と一致しない場合に、DNS 認証でのみ発生します。

この問題を解決するには、正しい CNAME レコードを DNS 構成に追加します。詳細については、DNS 構成に CNAME レコードを追加するをご覧ください。
RESOLVED_TO_NOT_SERVING このエラーは、ドメインに DNS A レコードと AAAA レコードが含まれており、証明書がロードバランサに接続されていない特定の IP アドレスを指している場合に発生します。

このエラーは、ロードバランサ認証を使用する証明書にのみ適用されます。ロードバランサ認証を使用して証明書をプロビジョニングできるのは、ロードバランサを構成した後のみです。

この問題を解決するには、ロードバランサの IP アドレスを指すようにドメインの DNS A レコードと AAAA レコードを更新します。ドメインの DNS A レコードと AAAA レコードから解決された IP アドレスは ips.resolved パラメータに保存され、この証明書が関連付けられているロードバランサの IP アドレスは ips.serving パラメータに保存されます。

ドメインの DNS A レコードと AAAA レコードは、ロードバランサの IP アドレスのみを参照する必要があります。たとえば、DNS A レコードがロードバランサの IP アドレスを指しているが、DNS AAAA レコードが別の IP アドレスを指している場合、RESOLVED_TO_NOT_SERVING エラーが発生します。

また、ドメインの DNS A レコードと AAAA レコードが世界中で正しく、一貫して解決されるようにする必要があります。詳細については、多視点ドメイン検証の失敗をご覧ください。
NO_RESOLVED_IPS このエラーは、ドメインに DNS A レコードと AAAA レコードが含まれていない場合に発生します。

このエラーは、ロードバランサ認証を使用する証明書にのみ適用されます。ロードバランサ認証を使用して証明書をプロビジョニングできるのは、ロードバランサを構成した後のみです。

この問題を解決するには、このドメインの DNS A レコードと AAAA レコードを追加し、レコードがターゲット HTTPS プロキシまたは Media CDN エッジ キャッシュ サービスの IP アドレスを指していることを確認します。

また、ドメインの DNS A レコードと AAAA レコードが世界中で正しく、一貫して解決されるようにする必要があります。詳細については、多視点ドメイン検証の失敗をご覧ください。
RESOLVED_TO_SERVING_ON_ALT_PORTS このエラーは、DNS A レコードと AAAA レコードを含むドメインが、この証明書がアタッチされているロードバランサの IP アドレスを指しているが、それらの IP アドレスでポート 443 が開いていない場合に発生します。

このエラーは、ロードバランサ認証を使用する証明書にのみ適用されます。ロードバランサ認証を使用して証明書をプロビジョニングできるのは、ロードバランサを構成した後のみです。

この問題を解決するには、証明書がアタッチされたロードバランサがポート 443 でリッスンしていることを確認します。ips.serving_on_alt_ports パラメータには、ポート 443 が開いていないロードバランサの IP アドレスのリストが格納されます。

また、ドメインの DNS A レコードと AAAA レコードが世界中で正しく、一貫して解決されるようにする必要があります。詳細については、多視点ドメイン検証の失敗をご覧ください。
CERTIFICATE_NOT_ATTACHED このエラーは、証明書がロードバランサにアタッチされていない場合に発生します。この問題を解決するには、証明書がロードバランサに接続されていることを確認します。詳細については、ロードバランサに証明書をデプロイするをご覧ください。

このエラーは、証明書がターゲット HTTPS プロキシに接続されている証明書マップの一部であるにもかかわらず、プロキシが転送ルールに接続されていない場合にも発生します。この問題を解決するには、ターゲット HTTPS プロキシを適切な転送ルールに関連付けます。詳細については、ターゲット プロキシの概要と転送ルールの概要をご覧ください。

このエラーは、ロードバランサ認証を使用する証明書にのみ適用されます。ロードバランサ認証を使用して証明書をプロビジョニングできるのは、ロードバランサを構成した後のみです。

ターゲット プロキシから証明書マップを切断するときに発生するエラー

ターゲット プロキシから証明書マップを切断すると、次のエラーが表示されます。

"There must be at least one certificate configured for a target proxy."

このエラーは、切断する証明書マップで指定された証明書以外のターゲット プロキシに割り当てられた証明書がない場合に発生します。 マップを切断するには、まず 1 つ以上の証明書をプロキシに直接割り当てます。

証明書マップエントリを証明書に関連付けるときのエラー

証明書マップエントリを証明書に関連付けると、次のエラーが表示されます。

"certificate can't be used more than 100 times"

このエラーは、すでに 100 個の証明書マップエントリに関連付けられている証明書に証明書マップエントリを関連付けようとした場合に発生します。この問題を解決するには、次の操作を行います。

  • Google マネージド証明書の場合は、別の証明書を作成します。新しい証明書マップエントリをこの新しい証明書に関連付け、新しい証明書をロードバランサに添付します。
  • セルフマネージド証明書の場合は、新しい名前で証明書を再度アップロードします。新しい証明書マップエントリをこの新しい証明書に関連付け、新しい証明書をロードバランサに添付します。

CA Service インスタンスによって発行された証明書に関連する問題

このセクションでは、Certificate Manager を使用して CA Service インスタンスによって発行された Google マネージド証明書をデプロイするときに発生する可能性がある最も一般的なエラーと、それらの考えられる原因について説明します。

Failed to create Certificate Issuance Config resources エラーが表示された場合は、次の点を確認してください。

  • ライフタイム。証明書の有効な存続時間の値は 21 ～ 30 日間です。
  • ローテーション時間枠の割合。有効なローテーション時間枠の割合は 1〜99 パーセントです。証明書の更新が、証明書の発行の 7 日以上後、期限切れの 7 日以上前に行われるように、証明書の有効期間を基準にしてローテーション ウィンドウの割合を設定する必要があります。
  • 鍵アルゴリズム。有効な鍵アルゴリズムの値は RSA_2048 と ECDSA_P256 です。
  • CA プール。CA プールが存在しないか、正しく構成されていません。CA プールには、有効な CA が少なくとも 1 つ含まれている必要があります。また、呼び出し元には、ターゲットGoogle Cloud プロジェクトに対する privateca.capools.use 権限が必要です。リージョン証明書の場合、証明書発行の構成リソースは CA プールと同じロケーションに作成する必要があります。

Failed to create a managed certificate エラーが表示された場合は、次の点を確認してください。

  • 証明書の作成時に指定した証明書発行の構成リソースが存在している。
  • 呼び出し元に、証明書の作成時に指定した証明書発行の構成リソースに対する certificatemanager.certissuanceconfigs.use 権限がある。
  • 証明書は、証明書発行構成リソースと同じロケーションにあります。

Failed to renew certificate エラーまたは Failed to provision certificate エラーが表示された場合は、次の点を確認してください。

  • Certificate Manager サービス アカウントには、この証明書に使用される証明書発行の構成リソースで指定された CA プールに対する roles/privateca.certificateRequester 権限が付与されています。

    次のコマンドを使用して、ターゲット CA プールの権限を確認します。

    gcloud privateca pools get-iam-policy CA_POOL
--location REGION

    以下のように置き換えます。

    • CA_POOL: ターゲット CA プールの完全なリソースパスと名前
    • REGION: ターゲット Google Cloud リージョン

  • 証明書発行ポリシーが有効になっています。詳細については、発行ポリシーの制限に関連する問題をご覧ください。

発行ポリシーの制限に関連する問題

Certificate Manager が、証明書発行ポリシーによって作成された証明書への変更をサポートしていない場合、証明書のプロビジョニングは失敗し、マネージド証明書の状態は Failed に変わります。この問題を解決するには、次のことを確認します。

  • 証明書の ID 制約で、サブジェクトとサブジェクト代替名（SAN）のパススルーが許可されている。
  • 証明書の最大有効期間の制約が、証明書発行の構成リソースの全期間よりも長い。

前述の問題では、CA Service がすでに証明書を発行しているため、CA Service の料金に従って課金されます。

Rejected for issuing certificates from the configured CA Pool エラーが表示された場合は、証明書発行ポリシーによって要求された証明書がブロックされていることを示します。エラーを解決するには、次の点を確認します。

前述の問題では、CA Service が証明書を発行していないため、CA Service から課金されません。

IAP ホスト名の照合に関する問題

Identity-Aware Proxy（IAP）で Certificate Manager を使用しているときに、予期せず The host name provided does not match the SSL certificate on the server というエラーが発生した場合は、そのホスト名に有効な証明書を使用していることを確認します。また、証明書マップで構成した証明書マップ エントリを一覧表示します。IAP で使用するすべてのホスト名またはワイルドカード ホスト名には、専用のエントリが必要です。ホスト名の証明書マップエントリがない場合は、証明書マップエントリを作成します。

証明書の選択中にプライマリ証明書マップ エントリにフォールバックするリクエストは、常に IAP によって拒否されます。

多視点ドメイン検証の失敗

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 アドレスが返されるようにします。
  • ロードバランサ認証方法を使用して Google マネージド証明書をプロビジョニングする場合は、DNS 構成でロードバランサの IP アドレスを明示的に指定する必要があります。CDN などの中間レイヤが原因で、予期しない動作が発生する可能性があります。IP アドレスには、リクエストパスにリダイレクト、ファイアウォール、CDN を介さずに直接アクセスできる必要があります。詳細については、このドキュメントの CDN の背後にあるロードバランサをご覧ください。
  • 任意の DNS グローバル反映チェッカーを使用して、関連するすべての DNS レコードが世界中で正しく、一貫して解決されているのを確認することをおすすめします。

構成の変更を確認する

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

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

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

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

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

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

次のステップ