【WEB制作】サーバ移行時のDNS設定とSSL証明書の設定タイミング

2025.06.13
この記事は約6分で読めます。
この点、初めてで疑問が出たので、Geminiに聞いた内容を参考までにメモしておきます_φ(･_･

サーバー移行時に、DNS設定（ドメイン切り替え）とSSL証明書の設定を同時に行うのが一般的ですが、先にHTTPで通信できている移行先のサーバーでHTTPS化を済ませておくことは可能であり、むしろ推奨される場合があるようです。

なぜ先行HTTPS化が推奨されるのか

  • リスクの最小化と問題の早期発見:

    DNS切り替えは、インターネット全体に情報が伝播するまでに時間がかかるため（DNS浸透）、切り替えた直後に問題が発生すると、原因の特定が難しくなります。

    先に移行先サーバーでHTTPS化を完了させ、テスト環境などでそのドメイン名（テスト用サブドメインやhostsファイルでの仮設定など）を使ってHTTPSでの接続テストを十分に行っておけば、DNS切り替え後にスムーズに本番稼働に移れます。

    具体的には、SSL証明書のチェーンが正しく機能しているか、Apache（またはNginx）の設定に誤りがないか、WordPressのMixed Contentが発生しないかなどを事前に確認できます。

  • ダウンタイムの短縮:

    DNS切り替え後にSSL証明書の設定を行う場合、DNSが浸透してから設定作業を行うことになるため、その間はサイトがHTTPで表示されるか、全く表示されない状態になる可能性があります。事前にHTTPS化を済ませておけば、DNS切り替え後すぐにHTTPSでサイトが利用可能になり、ダウンタイムを最小限に抑えられます。

  • 心理的安全性:

    移行作業は何かと不安がつきものです。事前にHTTPSで接続できることを確認しておけば、DNSを切り替える際の心理的な負担が軽減されます。

先行HTTPS化の具体的な手順

  1. 移行先サーバーでWordPressをHTTPでセットアップし、動作確認を行う。
  2. 取得済みのSSL証明書を移行先サーバーに配置し、ApacheのVirtual Host設定でHTTPS化を行う。
    この際、ServerName や ServerAlias は、最終的に使用する本番ドメインを設定します。 ただし、この時点ではまだ本番ドメインのDNSを移行先サーバーに向けてはいけません。
  3. hostsファイルを一時的に編集してテスト接続を行う。
    あなたのPCのhostsファイル（Windows: C:\Windows\System32\drivers\etc\hosts、Mac/Linux: /etc/hosts）に以下の行を追加します。

    これにより、あなたのPCからyourdomain.comにアクセスしようとすると、DNSを介さずに直接移行先サーバーに接続されます。 この状態でブラウザからhttps://yourdomain.comにアクセスし、SSL証明書が正しく機能し、WordPressがHTTPSで表示されることを徹底的に確認します。Mixed Contentエラーが出ていないか、すべてのリソースがHTTPSで読み込まれているかなどをチェックしてください。

  4. WordPressのサイトアドレスをHTTPSに更新する。
    上記のhostsファイル設定でHTTPSアクセスを確認後、WP-CLIを使用してWordPressのhomeとsiteurlをhttps://yourdomain.comに変更します。

    Bash

    この設定変更により、WordPressは自身がHTTPSで稼働していると認識し、内部リンクなどがHTTPSに切り替わります。

  5. DNSを移行先サーバーのIPアドレスに切り替える。 HTTPSでの動作確認が完了したら、ドメインレジストラやDNS管理サービスで、ドメインのAレコードを移行先サーバーのIPアドレスに変更します。 hostsファイルの変更は、DNS切り替え前に元に戻しておきましょう。
  6. DNS浸透後、本番環境での最終確認を行う。 DNSが完全に浸透すると、世界中から新しいサーバーへのアクセスがHTTPS経由で行われるようになります。

先にHTTPで通信できている移行先のサーバーにおいて、DNS設定の前に、先にHTTPS化を済ませておくことは可能で、これにより、DNS切り替え後のトラブルを避け、スムーズな移行を実現できるようです。

また、上記のような方法だとSSL証明書を２箇所に配置する形になるのですが、これは適切な方法なのでしょうか？_φ(･_･
移行前のサーバー（稼働中）と移行先のサーバーの2箇所に同じSSL証明書を配置することは、問題なく、サーバー移行時の一般的なプラクティスのようです。

なぜ問題ないのか

  1. SSL証明書の性質:

    SSL証明書は、特定のドメイン名に対して発行されます。サーバーのIPアドレスや物理的な場所には紐づきません。そのため、同じドメイン名を使用する複数のサーバーに同じ証明書をインストールしても、技術的な問題は発生しないようです。
    ※私はまだこちらをやってみたことがないので、なんとも言えませんが。。。

  2. 移行の安全性と連続性:

    • 先行HTTPS化の実現: 移行先サーバーで先にHTTPS化を完了させることで、DNS切り替え前に新しい環境でのHTTPS接続を完全にテストできます。これにより、切り替え後のトラブルのリスクを大幅に減らせます。
    • ダウンタイムの最小化: DNSが新しいサーバーに浸透するまでの間も、古いサーバーが引き続きリクエストを処理し、SSLで暗号化された通信を提供し続けます。DNSが完全に切り替わった後、古いサーバーは役割を終え、新しいサーバーがすべてのリクエストを処理するようになります。この間、ユーザー体験が途切れることなく、常にHTTPSで安全な接続が提供されます。
  3. ライセンス上の問題:

    多くの有料SSL証明書は、サーバーの数ではなく、ドメイン名に対してライセンスされます。そのため、同じドメイン名に紐づく証明書であれば、複数のサーバーで使用しても追加費用が発生したり、ライセンス違反になったりすることは通常ないようです。ただし、非常に特殊なライセンス形態の証明書の場合は、発行元に確認するのが最も確実です。一般的に利用されるドメイン認証 (DV)、企業認証 (OV)、EV証明書では問題となることは稀のようです。
    ※ただし、こちらの文言を過信せず、心配な方は発行元に確認するのが一番確実です！

運用上の注意点

  • 秘密鍵の管理: 同じ証明書を使うということは、同じ秘密鍵を複数のサーバーに配置するということです。秘密鍵は非常に機密性の高い情報なので、両方のサーバーで厳重に管理し、不正アクセスから保護することが重要です。
  • 移行後の古いサーバーの扱い: DNSが完全に新しいサーバーに切り替わり、古いサーバーへのアクセスが不要になったら、速やかに古いサーバーのウェブサービス（Apacheなど）を停止し、将来的にはサーバーをシャットダウンするか、SSL証明書関連のファイルを削除することを検討してください。これにより、セキュリティリスクを低減できます。

まとめ

移行作業中に一時的に2つのサーバーに同じSSL証明書が配置される状況は、サーバー移行のベストプラクティスを安全かつスムーズに進めるための、効果的なアプローチのようです。

あくまでGeminiに聞いた内容をもとにまとめていますが、SSL証明書の件など、気になる方は十分に調べていただいたり、発行元に確認いただくのが良いですね！

タイトルとURLをコピーしました