WordPressサイトのSSL証明書を更新する方法｜期限の確認・certbotの更新・有料証明書の差し替え

SSL 証明書の期限が切れると、ブラウザに「この接続ではプライバシーが保護されません」などの警告が出て、多くの訪問者はページを開けなくなります。Chrome では NET::ERR_CERT_DATE_INVALID というエラーコードが表示されます。この記事では、WordPress サイトの証明書の期限を確かめ、管理の方法に応じて更新する手順を説明します。内容は2026年10月時点のものです。

2026年に知っておきたい変更

証明書の更新を取り巻くルールは、ここ数年で大きく変わっています。

有料の証明書を「複数年契約」で買っていても、証明書そのものは200日以内に再発行と差し替えが必要になります。手作業での更新は回数が増えるため、できるだけ自動更新にして、期限の監視を自分で用意しておくことが大切です。

ステップ1：証明書の期限を確かめる

ブラウザでは、アドレスバーの左のアイコンから証明書の情報を開くと、有効期限と発行者（認証局）を確認できます。

コマンドで確かめる場合は、次のように実行します。-servername を付けないと、1台のサーバーで複数のサイトを動かしている場合に別のサイトの証明書が返ることがあります。

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate -issuer -subject

notAfter= が有効期限（グリニッジ標準時）、issuer= が発行者です。

ステップ2：証明書を誰が管理しているか確かめる

更新の方法は、証明書をどこが発行・管理しているかで変わります。

CDN を使っている場合、CDN とサーバーの間の通信にもサーバー側の証明書が使われる設定があります。CDN の管理画面で、サーバー側の証明書の期限も確認してください。

ステップ3：レンタルサーバーの無料 SSL の場合

レンタルサーバーの無料 SSL は、ふつうサーバー会社が自動で更新します。期限が切れそうなのに更新されない場合、よくある原因は次のとおりです。

• ドメインの DNS（A レコード）がそのサーバーを向いていない。サーバーを移転した、DNS を CDN に向けた、などの場合に起こります
• ドメインの契約が切れている、または DNS の設定が消えている
• .htaccess で、認証局がドメインを確かめるために読み込むファイル（/.well-known/acme-challenge/ の下）へのアクセスを止めている

サーバーの管理画面の SSL 設定で証明書の状態を確認し、エラーが表示されていればその内容に従って直します。原因がわからない場合は、サーバー会社のサポートに問い合わせてください。

ステップ4：VPS で certbot を使っている場合

証明書の一覧と期限を確かめる

sudo certbot certificates

証明書ごとに、名前（Certificate Name）、対象のドメイン、有効期限（Expiry Date）と残り日数が表示されます。

更新を試してから更新する

# 本番の証明書には触れずに、更新の手順だけを試す
sudo certbot renew --dry-run

# 期限が近い証明書を更新する
sudo certbot renew

certbot renew は、更新の時期が来た証明書だけを更新します。Certbot 4.0 以降は、有効期間の残りが3分の1を切ったときです（90日の証明書なら、残りおよそ30日）。それより前は、残り30日という固定の基準でした。時期が来ていない証明書は何もせずに終わるため、1日に何度実行しても問題ありません。

--force-renewal で時期の前に更新させることもできますが、Let's Encrypt には「同じドメインの組み合わせの証明書は7日間に5枚まで」という制限があります。何度も試すと発行できなくなるため、試すときは --dry-run を使います。

自動更新が動いているか確かめる

certbot は、入れ方に応じて systemd のタイマーか cron で自動更新を実行します。

# certbot のタイマーと、次回・前回の実行時刻
systemctl list-timers | grep -i certbot

# cron で実行している場合
grep -r certbot /etc/crontab /etc/cron.d/ 2>/dev/null

どちらにも何も出ない場合は、自動更新が動いていません。certbot をどの方法で入れたかを確認し、certbot の公式サイトの手順で入れ直すか、cron に certbot renew -q を登録します。

更新に失敗する場合

失敗の詳しい理由は /var/log/letsencrypt/letsencrypt.log に記録されます。

sudo tail -n 50 /var/log/letsencrypt/letsencrypt.log

HTTP で確認する方式（HTTP-01）でよくある原因は次のとおりです。

• ファイアウォールやクラウドのセキュリティグループで、80番ポートが閉じている
• ドメインの DNS が別のサーバーを向いている
• Web サーバーの設定で、/.well-known/acme-challenge/ へのアクセスを止めている

ワイルドカード証明書（*.example.com）は、DNS に TXT レコードを置く方式（DNS-01）でしか取得できません。--manual で手作業で取得した証明書は自動更新できないため、使っている DNS サービスに対応した certbot の DNS プラグインに切り替えるか、期限の前に手作業で取り直します。

更新後に Web サーバーを読み込み直す

証明書のファイルが新しくなっても、Web サーバーが読み込み直すまでは古い証明書が使われます。/etc/letsencrypt/renewal-hooks/deploy/ に置いた実行ファイルは、証明書の更新に成功したときだけ実行されます。

# Nginx の例（Apache なら systemctl reload apache2）
printf '#!/bin/sh\nsystemctl reload nginx\n' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-webserver.sh
sudo chmod 755 /etc/letsencrypt/renewal-hooks/deploy/reload-webserver.sh

ステップ5：有料の証明書を差し替える場合

有料の証明書は、期限の前に販売店や認証局で更新（再発行）を申し込み、新しい証明書をサーバーに設置します。

CSR を作る

申し込みに CSR（証明書署名要求）が必要な場合は、サーバーで秘密鍵と一緒に作ります。

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

example.com.csr の中身を申し込み画面に貼り付けます。example.com.key（秘密鍵）は外に出さず、ほかのユーザーに読まれない権限で保管してください。レンタルサーバーの場合は、管理画面で CSR を作れることが多いので、その案内に従います。

発行された証明書を設置する

認証局によるドメインの確認（メール・DNS の TXT レコード・ファイルの設置のいずれか）が済むと、証明書が発行されます。サーバー証明書と中間証明書をつなげたファイルを用意し、Web サーバーの設定でファイルの場所を指定します。

# Nginx の例
ssl_certificate     /etc/ssl/example.com/fullchain.pem;
ssl_certificate_key /etc/ssl/example.com/example.com.key;

# Apache 2.4.8 以降の例（中間証明書をつなげたファイルを指定する）
SSLCertificateFile    /etc/ssl/example.com/fullchain.pem
SSLCertificateKeyFile /etc/ssl/example.com/example.com.key

読み込み直す前に、証明書と秘密鍵が対になっているかを確かめます。2つの値が同じなら対になっています。

openssl x509 -noout -pubkey -in /etc/ssl/example.com/fullchain.pem | openssl sha256
openssl pkey -pubout -in /etc/ssl/example.com/example.com.key | openssl sha256

設定を確かめてから読み込み直します。

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

# Apache
sudo apachectl configtest && sudo systemctl reload apache2

中間証明書が抜けていると、パソコンのブラウザでは表示できても、スマートフォンや外部のサービスからはエラーになることがあります。

ステップ6：更新できたことを確かめる

ステップ1のコマンドをもう一度実行し、notAfter= が新しい日付になっていることを確かめます。ブラウザでは、古い証明書の情報が残っていることがあるため、別のブラウザやシークレットウィンドウでも確認します。

WordPress の側では、証明書を更新しても設定を変える必要はありません。ただし、WordPress がほかのサイトにつなぐとき（プラグインの更新や外部 API）の証明書エラーは、自分のサイトの証明書とは別の問題です。その場合は関連記事を参考にしてください。

期限を自分で監視する

Let's Encrypt の通知メールは終わっているため、期限の監視は自分で用意します。ステップ1のコマンドを cron で毎日実行して残り日数を調べる、外部の監視サービスを使う、などの方法があります。具体的な手順は WordPressサイトのSSL証明書の有効期限を自動監視してアラートを出す方法 で説明しています。

まとめ

• 期限は openssl s_client に -servername を付けて確かめる。発行者を見れば、誰が管理している証明書かの手がかりになる
• レンタルサーバーの無料 SSL が更新されないときは、DNS の向き先と管理画面の表示を確認する
• certbot は certbot renew --dry-run で試してから certbot renew。自動更新は systemctl list-timers で確かめ、deploy フックで Web サーバーを読み込み直す
• --force-renewal は Let's Encrypt の発行数の制限に触れやすいので、試すときは --dry-run を使う
• 有料の証明書は2026年3月以降の発行分が最長200日。複数年契約でも再発行と差し替えが必要
• Let's Encrypt の通知メールは終了しているので、期限の監視を自分で用意する

関連記事:

• Let's Encrypt の証明書を自動更新する設定と確認方法（certbot）
• WordPressサイトのSSL証明書の有効期限を自動監視してアラートを出す方法
• WordPressの「certificate has expired」エラーを解決する方法｜サイトの証明書切れと外部通信のエラーを切り分ける
• WordPressのSSL証明書エラーの直し方｜ERR_CERT系の原因別とcURL error 60