導入:WordPress公開前にHTTPSは必須
※前回は、WordPressをインストールして初期設定まで行いました。
まだの場合は、以下の記事もご覧ください。
WordPressのインストールまで完了すると、
とりあえずブラウザでサイトが表示される状態になります。
しかし、この状態のままインターネット上に公開するのは、
セキュリティ面・信頼性の面で十分とは言えません。
現在のブラウザでは、
HTTPS(SSL)が設定されていないサイトに対して警告が表示されることもあります。
WordPressを「公開できる状態」に近づけるためには、
HTTPS対応は避けて通れない作業です。
本記事では、
これまで構築してきた WordPress 環境に対して、
Let’s Encrypt を使って SSL(HTTPS)を設定する流れを整理します。
なお、本記事は VirtualBox 上の検証環境 を前提としています。
SSL証明書の実取得は本番VPSで行うことを想定し、
検証環境では「手順と考え方の確認」を目的とします。
今回の前提とSSL設定の流れ
この記事は、本番VPSを想定した事前検証として、VirtualBox 上の Ubuntu Server 24.04 を使用しています。
サーバー構成は以下の通りです。
- Ubuntu Server 24.04
- nginx
- PHP
- MariaDB
- WordPress
すでに HTTP で WordPress が表示できている状態を前提とします。
今回は、無料で利用できる SSL 証明書として広く使われているLet’s Encrypt を利用します。
証明書の取得と設定には、公式ツールである Certbot を使用します。
作業の流れは、次の通りです。
- Certbot をインストールする
- nginx と連携して SSL 証明書を取得する
- HTTPS で WordPress が表示されることを確認する
DNS設定や外部公開に関わる部分については、本番VPSでは追加で確認が必要になる点があるため、該当箇所で補足します。
Certbot のインストール
Let’s Encrypt の SSL 証明書を取得・管理するために、Certbot をインストールします。
Ubuntu Server 24.04 では、snap を使ったインストールが推奨されています。
まず、Certbot をインストールします。
sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot
インストール後、certbot コマンドが利用できるか確認します。
certbot --version
バージョンが表示されれば、Certbot のインストールは完了です。
nginx と連携して SSL 証明書を取得する
先に重要な注意事項を説明します。
Let’s Encrypt の SSL 証明書は、インターネット上から実際にアクセスできるサーバー に対して発行されます。
そのため、この手順が成功するのは次の条件を満たしている場合です。
- 独自ドメインを取得している
- ドメインがサーバーの 公開IPアドレス を指している
- TCP 80 / 443 番ポートが外部から到達可能である
これらの条件を満たした 本番VPS環境 では、以下の手順で SSL 証明書を取得できます。
一方で、VirtualBoxなどの検証環境では、サーバーを外部公開していない構成が一般的なため、SSL証明書の取得は失敗します。
ここでは、「成功する流れ」と「失敗する流れ」の両方を説明したいと思います。
本番VPS環境で成功する場合の流れ
nginx 用の Certbot プラグインを使って、SSL 証明書の取得と設定を同時に行います。
sudo certbot --nginx
コマンドを実行すると、対話形式で次の項目が表示されます。
- 連絡用メールアドレスの入力
- Let’s Encrypt 利用規約への同意
- HTTPS を有効化するドメインの選択
対象となるドメインを選択すると、Certbot が自動的に次の処理を行います。
- Let’s Encrypt から SSL 証明書を取得
- nginx の設定ファイルを更新
- HTTPS 用の設定を有効化
処理が正常に完了すると、指定したドメインに対して HTTPS が有効になります。
VirtualBoxなどの検証環境で実行した場合
本記事の検証環境では、サーバーがインターネット上から直接アクセスできません。
そのため、同じコマンドを実行しても、SSL 証明書の取得は多くの場合失敗します。
sudo certbot --nginx
対話形式の入力までは進みますが、証明書の検証段階でエラーが表示され、処理が中断されます。
表示されるエラーの例としては、次のようなものがあります。
- サーバーに接続できない
- タイムアウトが発生した
- Let’s Encrypt が指定された URL にアクセスできない
これらのエラーは、設定ミスや Certbot の不具合ではありません。
Let’s Encrypt 側からこのサーバーへインターネット経由でアクセスできないことが原因です。
VirtualBox 上の検証環境では、このエラーが出るのが 想定通りの挙動 になります。
HTTPSで表示されることを確認する
※以下は、外部公開された 本番VPS環境 での確認手順です。
Certbot の処理が完了したら、ブラウザで WordPress サイトにアクセスします。
URL が https:// から始まり、警告表示が出ていなければ、HTTPS は有効です。
あわせて、WordPress の管理画面にもアクセスし、通常通りログインできることを確認します。
ここまで問題なく動作していれば、SSL(HTTPS)の基本設定は完了です。
補足:HTTPS設定後に行う設定と注意点
SSL(HTTPS)が有効になっただけでは、WordPress を安全に、安定して公開できる状態になったとは言えません。
ここでは、HTTPS設定後に必ず確認・設定しておきたいポイントを整理します。
HTTP → HTTPS リダイレクトの設定
HTTPS が有効になっていても、HTTP(http://)でアクセスできる状態のままでは不十分です。
HTTP でアクセスされた場合は、自動的に HTTPS へ転送(リダイレクト) される必要があります。
nginx 設定の確認
Certbot を --nginx オプション付きで実行した場合、多くの環境ではHTTP → HTTPS リダイレクト設定が nginx の設定ファイルに自動で追加されます。
- 80番ポートで待ち受ける
- HTTPS(443)へリダイレクトする設定
この設定が入っていれば、HTTP でアクセスしても HTTPS に転送されます。
手動でリダイレクトを設定する場合
リダイレクト設定が入っていない場合は、80番ポート用の server ブロックにHTTPS への転送設定を追加します。
設定変更後は、次のコマンドで反映します。
sudo nginx -t
sudo systemctl reload nginx
ブラウザで http:// からアクセスし、自動的に https:// に切り替わることを確認してください。
SSL証明書の自動更新について
Let’s Encrypt の SSL 証明書は、有効期限が 90日 と短いのが特徴です。
そのため、自動更新が前提 の運用になります。
自動更新の仕組み
Ubuntu Server 24.04 では、Certbot は systemd の timer を使って期的に証明書の更新処理を行います。
多くの場合、インストール時点ですでに設定は完了しています。
自動更新の状態を確認する
systemctl list-timers | grep certbot
Certbot に関する timer が表示されていれば、自動更新は有効です。
テスト更新を実行する
sudo certbot renew --dry-run
エラーが表示されず完了すれば、自動更新は正常に動作すると判断できます。
本番VPS環境で実装する際の注意点
本番VPSで SSL 設定を行う場合は、次の点を必ず確認してください。
ドメインとDNS設定
- 独自ドメインが取得されていること
- ドメインが VPS の 公開IPアドレス を指していること
DNS の設定が反映されていない場合、Certbot は証明書を取得できません。
ポート開放とファイアウォール
- TCP 80 / 443 番ポートが外部から到達可能であること
- VPS事業者側のファイアウォール設定
OS 側(ufw 等)だけでなく、VPS管理画面側の設定も確認が必要です。
検証環境との違い
VirtualBox 環境では問題にならなかった点が、本番VPSでは影響することがあります。
- 外部ネットワークからの到達性
- セキュリティ設定
- 公開IPの有無
これらを前提に SSL 設定を行う必要があります。
まとめ
HTTPS を有効にすることで、
WordPress は「表示できる状態」から「公開できる状態」へ一歩近づきます。
- HTTP → HTTPS リダイレクト
- SSL証明書の自動更新
- 本番VPSでの注意点
これらをあわせて理解しておくことで、
後からのトラブルを防ぎやすくなります。
次のステップとしては、
- 本番VPS環境での HTTPS 設定
- WordPress 側の公開前チェック
などを検討するとよいでしょう。
以下のページに今回のシリーズ記事のまとめがあります。
ぜひご覧ください。



