「SSLを有効化する」とは何をしているのか
まず言葉をほぐします。
「SSLを有効化する」というのは、ざっくり言うと、
サイトのURLをhttp:// ではなく https:// で動かすようにする
そのために「証明書」をサーバーに設定し、通信を暗号化する
ということです。
ブラウザのアドレスバーで、
鍵マークが付いている
URLが https:// で始まっている
この状態が「SSL（正確にはTLS）が有効になっている」状態です。
なぜSSLがセキュリティ的に“必須レベル”なのか
通信内容が丸見えか、暗号化されているかの違い
SSLがない http:// の通信は、
ユーザー名
パスワード
問い合わせフォームの内容
クッキー（ログイン情報など）
といったデータが、そのまま平文でネットワークを流れます。
もし途中の経路（Wi-Fiスポット、プロバイダ、悪意ある中継者など）で盗み見されると、
その内容は簡単に読めてしまいます。
SSL（https）を有効化すると、
ブラウザとサーバーの間の通信が暗号化される
途中で盗み見されても、中身は解読しにくい
という状態になります。
特に重要なのは、
ログイン情報
クレジットカード情報
個人情報を含むフォーム送信
などが「丸見えではなくなる」という点です。
「なりすましサイト」との区別にも関わる
SSL証明書には、
このドメインは、このサーバーが正規の持ち主ですよ
という「身分証明」の役割もあります。
ブラウザは証明書を確認して、
本当にこのドメインの正当なサーバーか
怪しい自己署名証明書ではないか
をチェックします。
ユーザー側からすると、
鍵マークが付いている
証明書エラーが出ていない
ということが、
「少なくとも、明らかに怪しい“なりすまし”ではない」
という一つの目安になります。
WordPress にとってのSSLの意味
ログイン画面と管理画面を守る
WordPress サイトでは、
/wp-login.php（ログイン画面）/wp-admin/（管理画面）
で、管理者のユーザー名とパスワードがやり取りされます。
SSLがない状態だと、
カフェのWi-Fi
社内ネットワーク
ホテルのWi-Fi
などからログインしたときに、
その通信が盗み見されるリスクがあります。
SSLを有効化して https:// でログインすることで、
ログイン情報が暗号化される
セッションID（クッキー）も盗まれにくくなる
という、管理者自身を守る効果が生まれます。
フロント側（閲覧ページ）にも意味がある
「ログインしない一般ユーザーには関係ないのでは？」と思うかもしれませんが、
実はフロント側にも重要な意味があります。
フォーム送信（問い合わせ・会員登録など）の内容が守られる
クッキーやトラッキング情報が盗まれにくくなる
ブラウザの「安全ではありません」警告を避けられる
特に今のブラウザは、
http:// のフォームに対して「保護されていません」と警告を出すhttps:// でないログインフォームを嫌う
という挙動をします。
つまり、SSLを有効化していないと、
セキュリティ的に危ないだけでなく
ユーザーから見ても「なんか危なそうなサイト」に見える
というデメリットが出てきます。
例題：SSLなしとSSLありの違いをイメージする
ケース1：SSLなしでログインする
URLが http://example.com/wp-login.php のままのサイトで、
管理者がカフェのフリーWi-Fiからログインしたとします。
そのとき、
ユーザー名とパスワードは平文でネットワークを流れる
悪意ある人が同じWi-Fiにいれば、盗み見できる可能性がある
という状態です。
一度ログイン情報を盗まれると、
管理者としてログインされる
プラグインの追加・テーマの改ざん・ユーザーの追加など、何でもされうる
という、かなり致命的なリスクになります。
ケース2：SSLあり（https）でログインする
同じ状況でも、URLが https://example.com/wp-login.php で、
SSLが正しく有効になっていれば、
通信内容は暗号化される
途中で盗み見されても、簡単には読めない
という状態になります。
もちろん「絶対安全」ではありませんが、
少なくとも「平文でダダ漏れ」の状態からは脱出できます。
SSL有効化の“本質的なポイント”をエンジニア目線で整理する
ポイント1：通信路の暗号化（Confidentiality）
セキュリティの三大要素のひとつに「機密性（Confidentiality）」があります。
SSLはまさに、
ブラウザとサーバーの間の通信の機密性を高める
ための仕組みです。
プログラミングで言えば、
API通信を平文HTTPではなくHTTPSで行う
トークンやセッションIDを暗号化されたチャネルでやり取りする
というのと同じ発想です。
ポイント2：改ざん検知（Integrity）
SSL/TLSは、単に暗号化するだけでなく、
途中でデータが改ざんされていないか
もチェックします。
つまり、
途中の誰かがレスポンスを書き換える
フォーム送信内容を途中でいじる
といった攻撃に対しても、一定の防御になります。
ポイント3：サーバーの正当性確認（Authentication）
証明書は、
このドメインは、このサーバーが正規の持ち主です
という「サーバー側の認証」の役割も持ちます。
ユーザーは、
証明書エラーが出ていない
正規の認証局が発行した証明書である
ことを通じて、
「少なくとも、明らかに偽サイトではない」
という安心感を得られます。
「SSLを有効化して終わり」ではない、という話
WordPress 側のURL設定も合わせて変える必要がある
SSLをサーバー側で有効にしたら、
WordPress 側でも、
WordPress アドレス（URL）
サイトアドレス（URL）
を http:// から https:// に変更する必要があります。
これをしないと、
一部のリソースが http:// のまま読み込まれる
「混在コンテンツ（Mixed Content）」としてブラウザに警告される
といった問題が起きます。
セキュリティ的にも、
クッキーの扱い
リダイレクトの挙動
などに影響が出るので、
「サーバー設定＋WordPress設定」の両方をセットで考えることが大事です。
http から https へのリダイレクトも重要
SSLを有効化した後は、
http://example.com にアクセスしてきた人を
自動的に https://example.com にリダイレクトする
という設定も、ほぼ必須です。
これをやらないと、
http と https の両方でサイトが見えてしまう
一部のユーザーが未だに暗号化されていない通信を使ってしまう
という状態になります。
.htaccess やサーバー設定で、
「http で来たら必ず https に飛ばす」
というルールを入れるのが、実運用では定番です。
プログラミングの感覚で捉える「SSLを有効化」
これは「本番環境のAPIを必ずHTTPSにする」のと同じ
自分でAPIサーバーを作るとき、
本番環境ではHTTPS必須
HTTPはリダイレクトか拒否
という設計にするのが普通です。
WordPress サイトも同じで、
公開サイト（特にログインやフォームがあるサイト）は
HTTPSを前提にする
というのが、今の「当たり前の設計」です。
セキュリティの“前提条件”を満たす作業
多くのセキュリティ対策は、
SSLが有効であること
を前提にしています。
ログイン防御
セッション管理
クッキーの secure 属性
などは、SSLがないと本来の力を発揮できません。
つまり、
SSLを有効化するのは
「セキュリティ対策の一つ」というより
「他の対策がちゃんと意味を持つための前提条件」に近い位置づけです。
まとめ：SSL有効化は「守りのスタートラインに立つ」ための作業
「SSLを有効化」というテーマの本質は、
サイトの通信を http:// から https:// に切り替え
ブラウザとサーバーの間のやり取りを暗号化し
ログイン情報やフォーム送信内容を“丸見え”にしない
ということです。
押さえておきたいポイントは、
ログイン画面・管理画面を守るうえで、もはや必須レベル
フロント側のフォームやユーザーの安心感にも直結する
サーバー設定だけでなく、WordPressのURL設定とリダイレクトまで含めて考える
という3つです。
もし今あなたのサイトがまだ http:// のままなら、
それは「セキュリティ的にスタートラインに立てていない状態」です。
最初の一歩として、SSL有効化を“前提条件”としてクリアする——そこから、他のセキュリティ対策を積み上げていくイメージを持ってみてください。
