Webサイトで一般にSSLと呼ばれているのは、現在の通信規格ではTLSです。HTTPSはHTTPをTLSで保護し、ブラウザーとサーバーの間を暗号化します。途中で内容を読まれたり書き換えられたりする危険を減らします。
ただしHTTPSにすれば、サイトの内容やWordPressまで安全になるわけではありません。接続先の確認と通信経路の保護を担う仕組みとして理解し、更新・認証・フォームの保存先は別に管理します。
HTTPSは暗号化と接続先の確認を行う
TLSでは、通信相手と暗号方式を決めて共有鍵を作ります。以後の通信はその鍵を使って保護されます。サーバーは証明書と秘密鍵を用いて、自分が対象ドメインの接続先であることをブラウザーへ示します。秘密鍵は公開せずサーバー側で保護します。
ブラウザーは証明書の信頼の連鎖、有効性、アクセスしたホスト名との一致を確認します。証明書が有効でも別の名前へアクセスすれば警告になります。wwwありとなし、サブドメインなど、公開するすべての名前を証明書の対象と照合します。
証明書の価格と暗号強度を混同しない
DVはドメインの制御を確認して発行されます。OVやEVでは組織に関する追加確認がありますが、価格が高いほど通信の暗号が自動的に強くなるという関係ではありません。必要な認証方針や取引先要件がなければ、一般的な法人サイトでは自動更新できるDVも候補になります。
証明書ブランドだけで選ばず、対象ドメイン・自動更新・失敗通知・再発行方法を見ます。レンタルサーバーの管理画面で無料証明書を有効にできても、DNSやドメイン制御の確認に失敗すれば発行と更新は止まります。
有効化前に名前とDNSをそろえる
証明書を申し込む前に、公開するホスト名を決めます。DNSが対象サーバーへ向き、外部から確認できる状態が必要な発行方式があります。移転中に新旧どちらで証明書を取得するかは、切り替え手順と合わせます。
管理画面の「SSL有効」表示だけで完了にせず、実際にHTTPSで主要ページを開きます。証明書の対象名と期限を確認し、古いブラウザーや外部監視からも到達できるかを見ます。中間証明書の設定不備は一部の端末だけで警告になる場合があります。
DNSを切り替える前には、新サーバーが同じホスト名の証明書を提示できるか確認します。切り替え後もしばらく旧サーバーへ到達する利用者がいるため、新旧の両方で警告が出ない期間を確保します。
HTTPからHTTPSへの転送は公式機能を優先する
証明書を入れただけでは、HTTPのURLが残る場合があります。サーバーやアプリケーションの公式機能でHTTPSへ転送し、元のパスとクエリを保てるか確認します。汎用の.htaccessコードを環境を見ずに貼り付けると、転送ループや管理画面停止につながります。
WordPressではサイトURLもHTTPSへそろえます。転送を有効にする前に管理画面へ戻る方法を確認します。プロキシやCDNを使う構成では、利用者側がHTTPSでも元サーバー側の判定が異なるため、提供事業者の手順に従います。
混在コンテンツは参照元を直す
HTTPSのページからHTTPの画像やスクリプトを読むと、混在コンテンツになります。ブラウザーが読み込みを止める資源もあり、見た目だけでなくフォームや計測が動かなくなる場合があります。開発者ツールで対象URLと呼び出し元を確認します。
データベースを一括置換する前に、バックアップと対象範囲を決めます。テーマ、CSS、外部タグに固定URLが残る場合もあります。単に警告を隠すプラグインへ頼らず、HTTP参照を作っている設定やコンテンツを直します。
自動更新は失敗を検知して完成する
Let's EncryptはACMEを使い、ドメイン制御の確認から発行・更新を自動化できます。自動更新を設定しても、DNS変更・到達制限・アカウント問題などで失敗する可能性は残ります。期限切れの前に通知を受け取れるかを確認します。
法人サイトのHTTPS化は、証明書の有効化で終わりません。対象名・HTTP転送・混在コンテンツ・更新通知を一つの経路として試します。さらにWordPress更新とアカウント保護を別の対策として続けることで、TLSが担う範囲を正しく生かせます。