2026年5月20日

Let’s EncryptでWordPressをSSL化する手順（Certbot・Apache/Nginx）

セキュリティ

Let's Encrypt は、無料で SSL/TLS 証明書（サーバー証明書）を発行する認証局です。証明書の取得と更新は Certbot というツールで自動化でき、Apache や Nginx の設定の書き換えまで任せることもできます。

この記事は、root 権限で操作できる VPS やクラウドのサーバーで WordPress を動かしている場合の手順です。レンタルサーバーを使っている場合は、たいてい管理パネルに「無料 SSL」などの機能があり、そちらで設定します（自分で Certbot を入れることはできないのが一般的です）。

始める前に確認すること

ドメインの DNS がこのサーバーを向いていること。example.com と www.example.com の両方で証明書を取るなら、両方の A レコード（IPv6 を使うなら AAAA レコードも）がこのサーバーの IP アドレスになっている必要があります。
80 番ポートに外から届くこと。Let's Encrypt は HTTP（80 番）でドメインの持ち主かどうかを確かめます。ファイアウォールやクラウドのセキュリティグループで 80 番と 443 番を開けておきます。
Web サーバーの設定に、そのドメインの ServerName（Apache）または server_name（Nginx）がすでにあること。Certbot はこれを手がかりに設定を書き換えます。
作業前に WordPress のデータベースとファイルのバックアップを取ること。後の手順で URL を書き換えます。

# DNS がこのサーバーの IP アドレスを返すか確かめる
dig +short example.com A
dig +short www.example.com A

手順1: Certbot を入れる

Certbot の公式サイト（certbot.eff.org）は、snap でのインストールを案内しています。

# snap で入れる（公式の案内）
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
certbot --version

OS のパッケージで入れることもできます。apt や dnf で入れた Certbot と snap の Certbot を両方入れると、どちらが動いているのかわかりにくくなるため、どちらか一方にします。

# Ubuntu / Debian のパッケージで入れる場合
sudo apt update
sudo apt install certbot python3-certbot-apache   # Apache の場合
sudo apt install certbot python3-certbot-nginx    # Nginx の場合

# AlmaLinux / Rocky Linux 9 などは EPEL リポジトリから入れる
sudo dnf install epel-release
sudo dnf install certbot python3-certbot-apache   # Apache の場合
sudo dnf install certbot python3-certbot-nginx    # Nginx の場合

手順2: 証明書を取得する

Apache・Nginx の設定まで Certbot に任せる場合

いちばん手軽な方法です。証明書を取得し、HTTPS 用の設定を Web サーバーに追加し、HTTP から HTTPS への転送（リダイレクト）も設定します。

# Apache の場合
sudo certbot --apache -d example.com -d www.example.com

# Nginx の場合
sudo certbot --nginx -d example.com -d www.example.com

初回はメールアドレスの入力と利用規約への同意を求められます。Let's Encrypt は 2025年6月4日に証明書の期限切れを知らせるメールの送信を終了しているため、メールアドレスを登録しても期限切れの通知は届きません。更新は後の手順5 の自動更新で行います。

Apache の場合、Ubuntu では /etc/apache2/sites-available/ に名前が -le-ssl.conf で終わる HTTPS 用の設定ファイルが作られます。

証明書だけを取得し、設定は自分で書く場合

Web サーバーの設定を自分で管理したい場合は certonly を使います。--webroot は、Web サーバーを動かしたまま、ドキュメントルートに確認用のファイルを置いて認証する方法です。

sudo certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com

取得した証明書は次の場所に置かれます。Web サーバーの設定では fullchain.pem と privkey.pem を使います。

ファイル	中身
`/etc/letsencrypt/live/example.com/fullchain.pem`	証明書と中間証明書
`/etc/letsencrypt/live/example.com/privkey.pem`	秘密鍵
`/etc/letsencrypt/live/example.com/cert.pem`	証明書のみ
`/etc/letsencrypt/live/example.com/chain.pem`	中間証明書のみ

設定の練習や試行錯誤をするときは、--test-cert（--staging と同じ）を付けると、テスト用の環境から証明書を取得します。本番の環境には発行数の上限があるため、何度も失敗しそうなときはテスト用の環境で確かめてから本番で取得します。

手順3: Web サーバーの設定を確認する

certonly で取得した場合は、HTTPS の設定を自分で書きます。Nginx の例です。

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;   # Nginx 1.25.1 以降の書き方
    server_name example.com www.example.com;
    root /var/www/html;
    index index.php;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

http2 on; は Nginx 1.25.1 以降の書き方です。Ubuntu 24.04 の Nginx（1.24）のように古い版では、この行の代わりに listen 443 ssl http2; と書きます。nginx -v で版を確認できます。
PHP-FPM のソケットのパスは、入っている PHP の版によって変わります（例は PHP 8.3）。ls /run/php/ で確認します。
暗号スイートなどの細かい設定は、Mozilla の「SSL Configuration Generator」で、使っている Web サーバーと版に合った設定を作ると安全です。

Apache で自分で書く場合は、sudo a2enmod ssl で SSL モジュールを有効にし、HTTPS 用の <VirtualHost *:443> に SSLEngine on、SSLCertificateFile（fullchain.pem）、SSLCertificateKeyFile（privkey.pem）を書きます。

設定を変えたら、構文を確認してから読み込み直します。

# Nginx
sudo nginx -t && sudo systemctl reload nginx

# Apache（Ubuntu / Debian）
sudo apache2ctl configtest && sudo systemctl reload apache2

ブラウザで https://example.com/ を開き、鍵のマークが表示され、証明書の発行者が Let's Encrypt になっていることを確かめます。

手順4: WordPress の URL を HTTPS に切り替える

証明書を入れただけでは、WordPress は今までどおり http:// の URL でリンクや画像を出力します。WordPress の設定と、記事の中に書かれた URL を切り替えます。ここでは WP-CLI を使います。

# 作業前にデータベースを書き出しておく
wp db export backup-before-https.sql

# 「WordPress アドレス」と「サイトアドレス」を HTTPS にする
wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

# 記事などに書かれた http:// の URL を置き換える（まず --dry-run で件数を確認）
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --report-changed-only

# 管理画面とログインを HTTPS に限る
wp config set FORCE_SSL_ADMIN true --raw

# キャッシュを消す
wp cache flush

WP-CLI を使わない場合は、「設定」→「一般」の「WordPress アドレス (URL)」と「サイトアドレス (URL)」を https:// に変えます。記事中の URL の置き換えには、置き換え用のプラグインを使います。
wp search-replace は、シリアライズされたデータ（ウィジェットやプラグインの設定）も壊さずに置き換えます。guid の列は記事の識別子なので変えません。
http://www.example.com のように別の表記でも URL を書いている場合は、その表記についても置き換えます。

置き換えの後も、テーマやプラグインが http:// の画像やスクリプトを読み込んでいると、ブラウザが「保護されていない」部分があると警告します（混在コンテンツ）。ブラウザの開発者ツールのコンソールに出る警告から、読み込んでいる URL を探して直します。

Cloudflare やロードバランサーの後ろにある場合

HTTPS を手前のプロキシで終わらせ、WordPress のサーバーには HTTP で届く構成では、WordPress が HTTPS で開かれていることを判断できず、リダイレクトが繰り返されることがあります。その場合は wp-config.php の require_once ABSPATH . 'wp-settings.php'; より前に次を書きます。

<?php
// プロキシが付けるヘッダーを見て、HTTPS で開かれていると WordPress に伝える
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
	&& false !== strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) ) {
	$_SERVER['HTTPS'] = 'on';
}

このヘッダーは誰でも付けて送れるため、この設定はプロキシを通らないと WordPress のサーバーに届かない構成でだけ使います。

手順5: 自動更新を確認する

Certbot のパッケージは、証明書を自動で更新するタイマー（または cron）を一緒に入れます。更新の時期が来た証明書だけが更新されます。

# 更新の流れを試す（実際には更新しない）
sudo certbot renew --dry-run

# タイマーを確認する
systemctl list-timers | grep -i certbot

タイマーの名前は入れ方によって違います。snap では snap.certbot.renew.timer、Ubuntu / Debian のパッケージでは certbot.timer、EPEL のパッケージでは certbot-renew.timer です。EPEL の場合に一覧に出てこなければ、sudo systemctl enable --now certbot-renew.timer で有効にします。

--apache や --nginx で取得した証明書は、更新のあとに Certbot が Web サーバーを読み込み直します。certonly --webroot で取得した場合は、更新後に Web サーバーを読み込み直す処理（deploy フック）を自分で用意します。

# 証明書が更新されたときだけ Nginx を読み込み直すフックを作る
printf '#!/bin/sh\nsystemctl reload nginx\n' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

証明書の有効期間は短くなる予定

2026年10月時点で、Let's Encrypt の証明書の有効期間は標準で 90 日です。Let's Encrypt の発表では、標準の有効期間を 2027年2月に 64 日、2028年2月に 45 日へ短くする予定です。自分で cron に「毎月 1 日に更新」のような決め打ちの更新を書いていると間に合わなくなるため、更新は Certbot のタイマーに任せ、certbot renew で期限の近いものを更新する形にしておきます。

注意事項

HSTS（Strict-Transport-Security ヘッダー）を設定すると、指定した期間はブラウザが HTTP で開かなくなり、HTTPS をやめたくなっても戻しにくくなります。設定する場合は、まず短い max-age（例: 300 秒）で試してから長くします。
*.example.com のようなワイルドカード証明書は、HTTP での確認では取得できず、DNS の TXT レコードで確認する方法（DNS-01）が必要です。DNS サービスに対応した Certbot のプラグインを使うか、--manual --preferred-challenges dns で手作業で TXT レコードを登録します。手作業で登録する方法は、そのままでは自動更新できません。
証明書を取得できないときは、エラーメッセージに出るドメインと理由を確かめます。多いのは、DNS がまだ別のサーバーを向いている、80 番ポートが閉じている、.htaccess やリダイレクトの設定で確認用の URL（/.well-known/acme-challenge/）に届かない、のいずれかです。

まとめ

DNS と 80 番ポートを確認してから、snap か OS のパッケージで Certbot を入れる
certbot --apache または certbot --nginx で、証明書の取得と Web サーバーの設定をまとめて行う
WordPress は siteurl と home を HTTPS にし、wp search-replace で記事中の URL を置き換え、FORCE_SSL_ADMIN を設定する
自動更新は certbot renew --dry-run とタイマーで確認する。有効期間は 2027年以降に短くなる予定なので、更新は Certbot に任せる