GCP Certificate Manager で証明書を発行する手順｜DNS 認証で Google マネージド証明書を作りロードバランサーに付ける

GCP の Certificate Manager で Google マネージド証明書を発行するには、ドメインの所有確認（DNS 認証またはロードバランサー認証）を用意し、証明書を作成して、証明書マップ経由でロードバランサーのターゲットプロキシに関連付けます。DNS 認証を使えば、ロードバランサーへ切り替える前に証明書を発行でき、ワイルドカード証明書も扱えます。この記事では、DNS 認証を使った発行の手順を gcloud コマンドで順に説明し、発行が進まないときの確認方法と、従来の Compute Engine の SSL 証明書リソースとの違いもまとめます。

コマンドや項目名は Google Cloud のドキュメントに基づく例です。gcloud の版や対象のロードバランサーの種類（グローバル・リージョン）によって指定が変わることがあるため、実行前に公式ドキュメントで確認してください（2026年10月現在）。

事前に確認しておくこと

• ロードバランサーの種類：Certificate Manager の証明書マップは、主にグローバル外部アプリケーションロードバランサーで使います。リージョンのロードバランサーでは、証明書をリージョンに作成し、マップを使わずにプロキシへ直接関連付ける方式になるなど、手順が異なります
• DNS を編集できること：DNS 認証では CNAME レコードを1件追加します。Cloud DNS 以外の DNS サービスでも構いません
• CAA レコード：ドメインに CAA レコードを設定している場合、Google マネージド証明書を発行する認証局を許可しておく必要があります。Google のドキュメントでは、Google Trust Services（pki.goog）と Let's Encrypt（letsencrypt.org）の両方を許可するよう案内されています
• 権限：Certificate Manager の操作と、ターゲットプロキシの更新ができるロールが要ります。本番のプロジェクトでは、作業用のアカウントに必要な範囲だけを付与します

手順1：API を有効にする

gcloud services enable certificatemanager.googleapis.com

プロジェクトで初めて使う場合だけ必要です。以降のコマンドは、gcloud config set project で対象のプロジェクトを選んだ状態で実行します。

手順2：DNS 認証を作成する

ドメインごとに DNS 認証のリソースを作ります。

gcloud certificate-manager dns-authorizations create example-com-auth \
  --domain="example.com"

作成したら、DNS に追加するレコードの内容を表示します。

gcloud certificate-manager dns-authorizations describe example-com-auth

出力の dnsResourceRecord に、レコード名（_acme-challenge.example.com. の形）、種類（CNAME）、値（authorize.certificatemanager.goog. で終わる名前）が表示されます。この内容をそのまま DNS に登録します。

なぜ CNAME なのかというと、Google 側がこの CNAME の先で ACME の検証用レコードを管理し、更新のたびに自動で応答できるようにするためです。一度登録すれば、更新時に手作業は要りません。逆に、このレコードを消すと、次の更新で失敗します。

_acme-challenge に別の用途（ほかの認証局の DNS 検証など）で TXT レコードを置いている場合、同じ名前に CNAME は共存できません。既存のレコードがないかを先に確認します。複数のプロジェクトで同じドメインの証明書を扱う場合に、プロジェクトごとに異なるレコードを使う方式も用意されています。必要な場合は、公式ドキュメントで DNS 認証の種類の指定を確認してください。

手順3：DNS にレコードを登録して反映を確かめる

Cloud DNS を使っている場合は、コンソールまたは gcloud dns record-sets create で CNAME を追加します。反映されたかは、外部から問い合わせて確認します。

dig +short CNAME _acme-challenge.example.com

手順2で表示された値が返れば準備は完了です。

手順4：証明書を作成する

DNS 認証を指定して証明書を作成します。ワイルドカードを含める場合も、同じドメインの DNS 認証で扱えます。

gcloud certificate-manager certificates create example-com-cert \
  --domains="example.com,*.example.com" \
  --dns-authorizations=example-com-auth

作成直後は発行中の状態です。状態は次のコマンドで確認します。

gcloud certificate-manager certificates describe example-com-cert

managed の下の state が PROVISIONING から ACTIVE に変われば発行済みです。ドメインごとの認証の進み具合は authorizationAttemptInfo に表示されます。発行には数分から、条件によってはそれ以上かかることがあります。

手順5：証明書マップを作り、ロードバランサーに関連付ける

証明書マップは、「どのホスト名にどの証明書を使うか」の対応表です。

# マップを作成
gcloud certificate-manager maps create example-com-map

# ホスト名ごとにエントリを作成
gcloud certificate-manager maps entries create example-com-apex \
  --map=example-com-map \
  --hostname="example.com" \
  --certificates=example-com-cert

gcloud certificate-manager maps entries create example-com-wildcard \
  --map=example-com-map \
  --hostname="*.example.com" \
  --certificates=example-com-cert

最後に、ロードバランサーのターゲット HTTPS プロキシにマップを関連付けます。

gcloud compute target-https-proxies update example-https-proxy \
  --certificate-map=example-com-map

関連付けのときの注意

すでに従来の SSL 証明書リソース（gcloud compute ssl-certificates で作るもの）をプロキシに付けている場合、証明書マップを関連付けるとマップ側が優先されます。切り替えの前に、マップのエントリがすべてのホスト名を網羅しているかを確かめてください。抜けたホスト名があると、そのホスト名ではブラウザーに証明書のエラーが出ます。どのエントリにも当てはまらない接続に使う証明書は、--set-primary を付けたエントリ（プライマリ）で指定できます。

切り替え後は、外部から証明書を確認します。

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

発行が進まないときの確認

describe の結果で authorizationAttemptInfo の状態が失敗になっている場合、理由の欄を見ます。起きやすい順に確認します。

1. CNAME が登録されていない、または値が違う：dig で値を確認します。末尾のドットの有無や、DNS サービスの画面でドメイン名が二重に付く（_acme-challenge.example.com.example.com になる）入力ミスがよくあります
2. CAA レコードで認証局が許可されていない：dig CAA example.com で確認し、必要な認証局を追加します。サブドメインに個別の CAA がある場合はそちらも見ます
3. DNSSEC の不備：ドメインで DNSSEC を有効にしていて署名に問題があると、検証側が応答を受け取れません
4. 発行の回数の制限：短時間に作り直しを繰り返すと、認証局側の制限にかかることがあります。原因を直してから作り直します

ロードバランサー認証を使った場合は、ドメインの A/AAAA レコードがロードバランサーの IP を指していること、証明書が関連付けられたプロキシが 443 番で応答していることが条件です。DNS の切り替え前には発行できないため、移行を伴う場合は DNS 認証のほうが向いています。

従来の SSL 証明書リソースとの違い

gcloud compute ssl-certificates create --domains=... で作る Google マネージド証明書は、ロードバランサー認証だけで発行され、ワイルドカードに対応しません。Certificate Manager は、DNS 認証による事前発行、ワイルドカード、多数の証明書をマップで管理する用途に向いています。既存の構成を移す場合は、Certificate Manager 側で証明書を発行して ACTIVE になったことを確かめてから、マップを関連付けると、切り替え時の空白を避けられます。

まとめ

• 発行の流れは、API の有効化、DNS 認証の作成、CNAME の登録、証明書の作成、証明書マップの作成とプロキシへの関連付け、の順です。
• DNS 認証なら、ロードバランサーへの切り替え前に発行でき、ワイルドカードも扱えます。CNAME は更新にも使うので消さないでください。
• 状態は describe の state と authorizationAttemptInfo で確認します。進まないときは CNAME の値、CAA、DNSSEC の順に見ます。
• マップを関連付けるとプロキシ上の従来の証明書より優先されるため、すべてのホスト名のエントリを先に用意します。

• WordPressをGCPのロードバランサで複数台構成にする設定方法
• CAAレコードでSSL証明書の発行元を制限する方法