WordPressから移行する前に確認したいHTTPS証明書。DNS・CDN・オリジンの切り替え手順
公開日 ・更新日
WordPressから静的サイトやヘッドレスCMSへ移行するとき、証明書はDNSを切り替えたあとに考える項目ではありません。新しい環境で証明書を発行できるか、どこでTLSを終端するか、失敗したときに元のサイトへ戻せるかを先に決めます。切り替え当日に証明書を足すと、原因調査の範囲が広がります。
移行前に証明書の全体像を一覧化する
まず、公開サイトのドメインだけでなく、`www`、管理画面、API、プレビュー、フォーム、Webhookの受け口を一覧にします。各行へ、DNSの管理先、CDNやロードバランサーの有無、オリジンサーバーの接続方式、証明書の発行元、満了日時、更新担当者を書きます。
CDNで証明書を終端していても、CDNからオリジンへの接続が常に同じ条件とは限りません。公開入口だけ確認して「移行完了」とせず、利用者と内部サービスが接続する経路を分けて見ます。WordPressの管理画面、決済、予約、メール送信など、移行対象外に見える連携も対象です。
新環境で先に発行と反映を試す
DNSを本番へ向ける前に、新環境で証明書の発行と反映を試します。HTTP-01を使うなら、証明書を発行する認証局からポート80へ到達でき、所定のチャレンジファイルを返せるか確認します。DNS-01を使うなら、DNSのTXTレコードを追加・削除する担当と、反映を確認する方法を決めます。ワイルドカードが必要な構成では、DNS-01が前提になります。
実際の公開ドメインで事前に発行する場合は、既存サイトを止めずに認証できる方法を選びます。難しければ、まず一時ホスト名で新環境のTLS終端とアプリ動作を確認し、本番ドメイン用の認証手順は別に検証します。テスト用の証明書で満足せず、本番で返す証明書の名前とチェーンまで確かめます。
DNS切り替え後は入口と奥を別に見る
切り替え直後は、ブラウザでトップページを開くだけでは足りません。外部から見たDNS、CDNが返す証明書、オリジンへのTLS接続、HTTPSへのリダイレクト、フォーム送信、APIやWebhookの応答を順番に確認します。古いキャッシュや複数の接続先が残る時間もあるため、確認時刻と観測地点を記録します。
ページが表示されても、HTTPの画像やスクリプトが残っていれば混在コンテンツになります。移行前後でURLを置換し、ブラウザのコンソールと実際のフォーム送信を確認します。証明書の問題とアプリのURL設定を、同じ担当者だけで抱え込まないことが重要です。
戻す条件を先に決める
HSTSを設定しているサイトでは、証明書エラーを利用者が通り抜けられない場合があります。切り替え前に、新旧両方の証明書が有効であること、戻すDNS先がまだ応答すること、切り戻し後もフォームやAPIが動くことを確認します。
停止条件は「トップページが見えるか」ではなく、証明書の名前と期限、チェーン、主要な送信経路、外部連携まで含めて決めます。移行は新しいCMSを置くだけではなく、接続を安全に保ったまま運用責任を移す作業です。証明書を先に一覧化し、発行・切り替え・監視・復旧を一つの手順にまとめれば、当日の判断を減らせます。
WordPressからの移行計画とHTTPSの切り替え条件を、現行のDNS・CDN構成に合わせて整理したい方は、COZITOへご相談ください。
関連記事
著者: 松井 勇樹