2026.10.30

【2026年版】SSL証明書の有効期間が200日→47日に短縮｜手動更新をやめて自動化する手順と期限切れの監視

soflan ・読了 6分

はじめに

Web サイトの HTTPS に使う SSL/TLS 証明書の有効期間が、段階的に短くなっています。ブラウザの会社と認証局が決める業界のルール（CA/Browser Forum）で、2025 年 4 月に決まりました。すでに 2026 年 3 月 15 日から、新しく発行される証明書の上限は 200 日になっています。

最終的に 47 日になると、年に 1 回、手で証明書を入れ替える運用は回らなくなります。この記事では、短縮の日程と、自動化の方法、期限切れを防ぐ監視をまとめました。

短縮の日程

発行日	最大の有効期間	手動で更新するなら（目安）
〜2026 年 3 月 14 日	398 日	年 1 回
2026 年 3 月 15 日〜	200 日	年 2 回
2027 年 3 月 15 日〜	100 日	年 4 回
2029 年 3 月 15 日〜	47 日	年 8 回以上

すでに発行済みの証明書は、そのまま期限まで使えます。次に発行するときから新しい上限になります
ドメインの持ち主かどうかの確認（DCV）を使い回せる期間も、最終的に 10 日まで短くなります。発行のたびに確認の手続きが要る、と考えておきましょう
有料の証明書で「数年契約」を買っていても、証明書そのものは上限の期間ごとに発行し直しになります

なぜ短くするのか

証明書の秘密鍵が漏れたり、ドメインの持ち主が変わったりしたとき、古い証明書が長く使える状態が残るのを防ぐためです。期限が短ければ、問題のある証明書も早く使えなくなります。

Let's Encrypt も短くなる

無料の証明書で多く使われている Let's Encrypt は、今は 90 日です。2025 年 12 月に、45 日まで段階的に短くすると発表しました。

日付	変わること
2026 年 5 月 13 日	希望した人向けの「tlsserver」プロファイルが 45 日に（試したい人向け）
2027 年 2 月 10 日	既定の「classic」プロファイルが 64 日に（ドメインの確認の使い回しは 10 日）
2028 年 2 月 16 日	既定の「classic」プロファイルが 45 日に（使い回しは 7 時間）

Let's Encrypt によると、自動で更新している人の多くは何もしなくてよいものの、「60 日ごとに更新」のような固定の間隔では足りなくなるとしています。更新のタイミングを、次の節のように見直しましょう。

対策 1：ACME で自動化する

証明書の発行と更新を自動で行う決まった手順（プロトコル）が ACME です。Let's Encrypt のほか、多くの有料の認証局も ACME に対応しています。代表的な道具は次のとおりです。

certbot：いちばん使われている ACME のクライアント。Apache・nginx の設定も書き換えられます
acme.sh：シェルだけで動く軽いクライアント。DNS での確認にも強い
Caddy・Traefik：Web サーバー・リバースプロキシ自体が証明書を自動で取って更新します

certbot の自動更新を確かめる

すでに certbot を入れているなら、自動更新が動いているかを確かめましょう。

bash

# 自動更新のタイマーが動いているか（パッケージで入れた場合）
systemctl list-timers | grep certbot

# 本番の証明書を使わずに、更新を試す
sudo certbot renew --dry-run

# 今ある証明書と期限の一覧
sudo certbot certificates

更新したあとに Web サーバーを読み込み直す必要があるときは、certbot の deploy-hook で読み込み直しのコマンドを指定しておきます。証明書は新しくなったのに、Web サーバーが古い証明書を持ったまま、という事故がよくあります。

bash

# 更新に成功したときだけ nginx を読み込み直す
sudo certbot renew --deploy-hook "systemctl reload nginx"

更新のタイミング

ARI（ACME Renewal Information）に対応したクライアントなら、いつ更新すべきかを認証局が教えてくれます。使っているクライアントの説明書で対応を確かめましょう
ARI を使わないなら、有効期間の 3 分の 2 くらいで更新するのが目安です（45 日なら 30 日ごろ）
1 日 1〜2 回、更新が必要かを確かめる設定にしておけば、期間が短くなっても追いつけます

対策 2：見落としやすい場所を洗い出す

Web サーバーの証明書は自動化していても、ほかの場所に同じ証明書をコピーしていると、そこが期限切れになります。

ロードバランサー・CDN・WAF に手でアップロードしている証明書
メールサーバー（SMTP・IMAP）や、社内のツールで使っている証明書
ルーターや NAS、ネットワーク機器などの管理画面
アプリに証明書の中身を埋め込んでいる（証明書のピン留め）場合。頻繁に変わると動かなくなるので、見直しが必要です

どこで、どの証明書を、誰が更新しているかを一覧にしておくと、短縮が進んでも慌てずに済みます。

対策 3：期限切れを監視する

自動化しても、設定の間違いや認証局の障害で更新に失敗することがあります。期限が近いことに気づけるしくみを用意しましょう。

bash

# サイトの証明書の期限を確かめる（example.com を自分のドメインに）
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

# 14 日（1209600 秒）以内に切れるなら終了コード 1 になる（監視のスクリプトに使える）
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -checkend 1209600