☰

ダウンタイムなしで Google マネージド証明書に移行するにはどうすればよいでしょうか?

tag-icon • tag-icon ssl-certificate google-cloud-platform load-balancing google-compute-engine
ダウンタイムなしで Google マネージド証明書に移行するにはどうすればよいでしょうか?

example.com を外部（Google 以外）のホスティング プロバイダから GCP に移行しています。

ロード バランサを設定するときに、Google が管理する証明書を検証するには、example.com をロード バランサにポイントする必要があることに気付きました。

example.com の A レコードを新しいロード バランサーの (静的) IP に変更するだけで、検証されます。

問題は、example.com へのトラフィックがすでに多く、example.com がロード バランサーを指し始めてから証明書が検証される前に発生するリクエストによって SSL エラーが生成され、ユーザーが非常に不満を抱くことになることです。

誰かこれを解決しましたか？方法はあると知っていますダウンタイムを回避する回転する証明書しかし、ダウンタイムなしで大規模なサイトを移行する方法が必ずあるはずです。

答え1

他の回答も非常に良いのですが、私は、基本的に証明書が発行されるのを待つだけのダウンタイムを計画せずに GCP ロード バランサに移行する方法を見つけたいと思っていました。この質問にはかなり多くのトラフィックがあり、計画とテストを行えばダウンタイムは不要であることが判明したため、独自の回答を追加します。

私がやった方法は次のとおりです:

  1. example.com の一時的な Let's Encrypt 証明書を発行します。
  2. 証明書を自己管理証明書としてインポートします。
  3. 自己管理証明書を使用するようにロードバランサーを設定します。
  4. ロードバランサーを指すように DNS レコードを更新します。
  5. Google管理の証明書を作成し、それを2番自己管理証明書の横にある証明書。
  6. Google マネージド証明書が発行されるまでお待ちくださいACTIVE。これには長い時間がかかる場合があります。セルフマネージド証明書がないと、この時点でダウンタイムが発生します。
  7. 証明書がすべての Google Front End (GFE) に伝播するまで 30 分間待ちます。
  8. これで、ロードバランサに 2 つの証明書が割り当てられました。Google が管理する証明書のみを使用するように更新します。完了です。

詳細

この問題を要約すると、Google が管理する証明書には、証明書がすでに割り当てられているロードバランサを指す DNS レコードが必要です。そうしないと、証明書は発行されません。証明書の発行には最大 1 時間かかることがあり、その間に SSL エラーが発生しないようにする必要があるため、問題が発生します。

私が見つけた回避策は自己管理証明書移行中に、ドメインが GCP ロードバランサを指し、証明書がすでに発行されたら、Google が管理する証明書に切り替えます。

私は暗号化しましょう証明書はありますが、他のものでも同様に機能します。これの利点は、すでにLet's Encrypt証明書を使用していたため、心配する必要がなかったことです。証明書の互換性。

私が行ったことの簡略版を以下に示します。ロード バランサのターゲット プロキシはmy-target-proxy、証明書はlb-certificate-letsencryptおよび と呼ばれますlb-certificate-managed。ドメイン名はexample.comおよびですsubdomain.example.com。

前提条件:

Let's Encrypt によって署名された、自己管理証明書として使用する新しい証明書を生成します。

openssl genrsa -out letsencrypt.pem 2048

openssl 構成ファイルを作成します。

オープンSSL

[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements

[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list

[dn_requirements]
countryName               = Country Name (2 letter code)
stateOrProvinceName       = State or Province Name (full name)
localityName              = Locality Name (eg, city)
0.organizationName        = Organization Name (eg, company)
organizationalUnitName    = Organizational Unit Name (eg, section)
commonName                = Common Name (e.g. server FQDN or YOUR name)
emailAddress              = Email Address

[sans_list]
DNS.1                     = example.com
DNS.2                     = subdomain.example.com

生成する証明書署名要求:

openssl req -new -key letsencrypt.pem -out letsencrypt.csr -config openssl.conf

Let's Encrypt から署名された証明書を取得します。

certbot certonly --csr letsencrypt.csr --manual --preferred-challenges dns

所有権を確認するには、certbot によって示された DNS レコードを更新します。他のチャレンジも機能する可能性がありますが、DNS が最も簡単なようです。

どのファイルが完全な証明書チェーンであるかをメモし、0003_chain.pem必要に応じて例を置き換えます。

完全な証明書チェーンは次の場所に保存されます: ...

GCP にセルフマネージド証明書をアップロードして作成します。

gcloud compute ssl-certificates create lb-certificate-letsencrypt \
  --certificate=0003_chain.pem \
  --private-key=letsencrypt.pem \
  --global

移行先のロード バランサを作成するか、自己管理証明書を使用するように構成します。

gcloud beta compute target-https-proxies create my-target-proxy \
  --ssl-certificates=lb-certificate-letsencrypt [url-map and other options]
# Or
gcloud beta compute target-https-proxies update my-target-proxy \
  --ssl-certificates=lb-certificate-letsencrypt

DNS レコードを更新して、ロード バランサーの IP を指定します。これで、example.com と subdomain.example.com の TLS を終了できるはずです。この手順をテストするには、hosts ファイルに example.com のレコードを追加し、ロード バランサーの IP を指定します。John Hanley の回答には、これに関する多くの有益なアドバイスが記載されています。

管理対象証明書を作成します。

gcloud compute ssl-certificates create lb-certificate-managed \
  --domains=example.com,subdomain.example.com \
  --global

Google 管理の証明書ではワイルドカードはサポートされていないため、使用中のすべてのドメインを必ずリストしてください。

ターゲットプロキシに割り当てる一緒に自己管理証明書を使用します。証明書はプロキシに割り当てられるまでプロビジョニングされません。

gcloud beta compute target-https-proxies update my-target-proxy \
  --ssl-certificates=lb-certificate-letsencrypt,lb-certificate-managed

ステータスを確認します:

gcloud compute ssl-certificates describe lb-certificate-managed

からstatusに変わるまで待ちます-PROVISIONINGACTIVEその他のステータス調査が必要なエラーです。「Google 管理の証明書のプロビジョニングには最大 60 分かかる場合があります。」ドキュメントによると(Let's Encrypt は同じことを数秒で実行します...)。

ロードバランサーが使用できるようになるまでにさらに 30 分かかる場合があります。

したがって、30分待つステータスが に変更された後ACTIVE。

Google 管理の証明書のみを使用するようにターゲット プロキシを更新します。

gcloud beta compute target-https-proxies update my-target-proxy \
  --ssl-certificates=lb-certificate-managed

新しい設定が反映されるまでにはしばらく時間がかかることがあります。ブラウザまたは openssl を使用してエンドポイントの発行者を確認してください。

openssl s_client -connect example.com:443 -showcerts \
  -CAfile /etc/ssl/certs/ca-certificates.crt <<< Q

発行者は「Let's Encrypt」ではなく「Google Trust Services LLC」になります。

自己管理型の Let's Encrypt 証明書は削除できるようになりました。また、管理対象の証明書に問題がある場合に備えて、有効期限が切れるまで保持しておくこともできます。

使用されていない自己管理型 Let's Encrypt 証明書をクリーンアップするには、次のコマンドを実行します。

gcloud compute ssl-certificates delete lb-certificate-letsencrypt

答え2

ダウンタイムが発生します。

ダウンタイムを最小限に抑えるには、次のヒントに従ってください。適切な計画を立てれば、ダウンタイムは非常に短くなり、場合によっては自動再試行によってクライアントにそれが見えなくなります。

ただし、サイトのデザイン、Cookie の使用、認証、セッション管理などについてはわかりません。避けられない中断が発生する可能性があります。可能であれば、サイトのメンテナンスの前に顧客に電子メールを送信して知らせることを検討してください。

ログを確認するには良いタイミングです。IP アドレスへのアクセスに関する潜在的な問題を探します。移行が完了し、古いシステムをシャットダウンすると、こうした種類の問題が発生し始めます。

  1. DNS リソース レコードはグローバルにキャッシュされることに注意してください。リソース レコードの TTL は、その長さに関するヒントを提供します。DNS リゾルバーは、TTL を独自に解釈して自由に使用できます。

  2. 変更するリソース レコードの TTL を書き留めます。次に、TTL を 1 分などの短い値に変更します。

  3. 最終的な変更を行う前に、少なくとも古い TTL が期限切れになるまで待ちます。

  4. DNS を変更する前に、サービスとロード バランサーを設定します。IP アドレスのみを使用してサービスが正しく動作することを確認します。IP をドメインに、または HTTP を HTTPS にリダイレクトする場合は、それらの機能を一時的に無効にして、後で有効にします。

  5. certbot を手動モードで使用して、ロード バランサに読み込むことができる証明書を作成します。これにより、ロード バランサが SSL 証明書を作成して検証を待つ手順がなくなります。後で Google マネージド SSL に切り替えることができます。

  6. Google Cloud Load Balancer の HTTP および HTTPS フロントエンドの両方を構成します。フロントエンドで Let's Encrypt SSL 証明書を構成します。

  7. 移行後、古いサイトを約 30 日間稼働させたままにすることを計画してください。通常、移行後、古いサイトでは数週間にわたってトラフィックが発生します。

  8. トラフィック量が最も少ない時間帯または曜日を選択します。次に、DNS リソース レコードを切り替えます。新しい TTL がキャッシュに使用されるように、古い TTL 値が期限切れになっている必要があることに注意してください。

  9. 数日後、すべてが機能していることを確認したら、TTL値を次のように通常の値に設定します。604800これは 1 週間の秒数、または 86400 (1 日) です。使用されている場合は、サイト リダイレクト (IP -> ドメイン、HTTP -> HTTPS) を再度有効にします。

答え3

これまでの提案に加えて、Google が管理する SSL 証明書は、リージョン外部 HTTP(S) ロードバランサと内部 HTTP(S) ロードバランサではサポートされていないことに注意してください。これらのロードバランサでは、セルフマネージド SSL 証明書を使用する必要があります。使用しているロードバランサの種類はわかりませんが、この移行を設定する前にそれを考慮する必要があります。また、これと同じガイドGoogle マネージド SSL 証明書の作成方法と使用方法、および正しく動作させるための考慮事項を確認できます。1。

証明書がすべての Google Front End (GFE) で利用できるようになるまでには最大 30 分かかる可能性があるため、これらの変更に対してメンテナンス ウィンドウを設定することをお勧めします。

さらに、ここ この動作を実現するための手順を説明した公式ガイドが表示されます。

1 https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs

2 https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#migrating-ssl

関連情報