ブラウザに「この接続は安全ではありません」と表示された。こうした連絡が急に入ることがあります。
SSL 証明書の有効期限切れは、対処自体は難しくない場合がほとんどです。ただし「自動更新が設定されているはずなのに切れた」という状況の原因特定には、いくつかの確認が必要です。この記事では、対処と調査の手順を整理します。
まず確認する:証明書の有効期限
コマンドで確認する
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -dates
notAfter が有効期限です。
notBefore=Jun 1 00:00:00 2026 GMT
notAfter=Aug 31 23:59:59 2026 GMT
有効期限まで何日あるかを確認する
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -checkend 604800
604800 は7日間(秒換算)です。「Certificate will expire」と出れば7日以内に切れます。数値を変えることで任意の日数で確認できます。
期限が切れている・数日しかない場合
猶予がない場合は、まず通常の更新コマンドを試します。Let’s Encrypt(Certbot)では、有効期限まで30日を切った証明書が自動的に更新対象になります。
sudo certbot renew
更新後は、Web サーバーに証明書を再読み込みさせます。
systemctl reload nginx # Nginx の場合
systemctl reload apache2 # Apache の場合
reload は設定ファイルと証明書を読み直す操作です(サービスの停止・再起動は不要です)。Certbot に deploy hook が設定されている場合は、更新完了後に自動で reload が実行されます。
–force-renewal は最終手段として使う
certbot renew を実行しても「更新期限に達していない」と判断されて更新されない場合、特定のドメインを指定して強制更新できます。
sudo certbot renew --cert-name example.com --force-renewal
ただし --force-renewal は有効期限を無視して証明書を再取得するため、短時間に繰り返すと Let’s Encrypt のレート制限(同一ドメインへの発行回数制限)に抵触する可能性があります。通常の certbot renew で対応できない場合の最終手段として使ってください。
商用証明書(DigiCert・GlobalSign など)の場合は、証明書プロバイダーの管理画面から更新手続きを行い、新しい証明書ファイルをサーバーに設置します。手順はプロバイダーによって異なるため、管理画面の案内に従ってください。
自動更新の設定を確認する
Let’s Encrypt(Certbot)の場合
多くのサーバーで Let’s Encrypt の証明書が使われています。Certbot での自動更新が設定されている場合、以下で確認できます。
# ドライランで更新が通るかテスト
certbot renew --dry-run
# タイマーまたは cron の確認
systemctl status certbot.timer # systemd の場合
crontab -l | grep certbot # cron の場合
--dry-run でエラーが出なければ、実際の更新も通る可能性が高いです。
サーバーに登録されている証明書の一覧を確認する
certbot certificates
ドメインごとの証明書と有効期限が一覧表示されます。管理しているドメインが意図した証明書で保護されているかも確認できます。
自動更新が動かない原因を調べる
「設定されているはずなのに切れた」というケースでよく見つかる原因です。
ポート 80 が塞がれている
Let’s Encrypt の HTTP-01 チャレンジは、ポート 80 への外部からのアクセスが必要です。ファイアウォールの設定変更やリバースプロキシの追加後に、ポート 80 へのアクセスが遮断されていることがあります。
ss -tlnp | grep :80
ポートが空いていても、外部からの疎通確認も必要です。
cron・systemd timer が止まっている
cron デーモン自体が停止していると、Certbot の定期実行も止まります。確認方法は「cron ジョブが動いていないと気づいたときの調査手順」を参照してください。
Certbot の設定ファイルが引き継がれていない
サーバーを再構築・移行した際に、Certbot の設定ファイル(/etc/letsencrypt/)が移行先に存在しないケースがあります。新しいサーバーで再取得が必要です。
有効期限は今後さらに短くなる
SSL 証明書の最大有効期間は、業界全体で段階的に短縮される方向に動いています。
これまでの変化
| 時期 | 最大有効期間 |
|---|---|
| 〜2015年頃 | 最長5年 |
| 2018年 | 825日(約2年3ヶ月)に短縮 |
| 2020年9月 | 398日(約13ヶ月)に短縮 |
| Let’s Encrypt(現在) | 90日(発行当初から) |
今後の決定済みスケジュール
CA/Browser フォーラム(証明書の業界標準を策定する組織)は 2025年4月に Ballot SC-081 を可決し、最大有効期間の段階的な短縮を決定しました。
| 適用開始日 | 最大有効期間 |
|---|---|
| 2026年3月15日 | 200日 |
| 2027年3月15日 | 100日 |
| 2029年3月15日 | 47日 |
また Let’s Encrypt は、独自に 2028年までに発行期間を現在の 90日から 45日へ短縮すると発表しています。
参考資料:
- CA/Browser Forum「Baseline Requirements」初期版(60ヶ月=約5年の上限): https://cabforum.org/uploads/Baseline_Requirements_V1.pdf
- CA/Browser Forum「Baseline Requirements v1.4.4」(2018年3月以降の 825日上限): https://cabforum.org/uploads/CA-Browser-Forum-BR-1.4.4.pdf
- Apple「About upcoming limits on trusted certificates」(2020年9月以降の 398日上限): https://support.apple.com/en-us/102028
- CA/Browser Forum「Baseline Requirements」現行版 6.3.2(2026年以降の 200日・100日・47日上限): https://cabforum.org/working-groups/server/baseline-requirements/requirements/#632-certificate-operational-periods-and-key-pair-usage-periods
- Let’s Encrypt FAQ(現在の既定有効期間 90日): https://letsencrypt.org/docs/faq/#what-is-the-lifetime-for-lets-encrypt-certificates-for-how-long-are-they-valid
- Let’s Encrypt「Why ninety-day lifetimes for certificates?」(90日証明書の理由): https://letsencrypt.org/2015/11/09/why-90-days.html
- Let’s Encrypt「Decreasing Certificate Lifetimes to 45 Days」(2028年までの 45日化): https://letsencrypt.org/2025/12/02/from-90-to-45.html
自動化が「推奨」から「必須」へ
有効期間が 47日になると、約6週間ごとの更新が必要になります。この頻度では、手動管理は現実的ではありません。
自動更新(Certbot + systemd timer または cron)が正しく動いているかを今のうちに確認・整備しておくことが、今後の運用負担を下げる最も効果的な対策です。複数ドメインを管理している場合は特に、更新の成否を通知する仕組みも合わせて用意しておくことをお勧めします。
おわりに
Let’s Encrypt が普及してから証明書の更新は自動化されることが多くなりましたが、自動更新が止まっていても通知が来ないまま期限切れになるケースは今でも見かけます。
certbot certificates や openssl s_client で定期的に有効期限を確認しておくと、慌てずに対処できます。
証明書の期限切れへの対処や、自動更新が動かない原因の調査は障害調査・原因分析からご相談ください。