SSL/TLS 証明書の有効期間短縮（200→100→47 日）と自動更新

証明書の有効期間は、いつ・どれだけ短くなりますか？

CA/Browser Forum の Ballot SC-081v3（2025 年 4 月可決）により、最長有効期間は 2026 年 3 月 15 日以降の発行分で 200 日、2027 年 3 月 15 日以降で 100 日、2029 年 3 月 15 日以降で 47 日になります。それまでは 398 日でした。発行済みの証明書は、期限まで使えます。

ブラウザに信頼される証明書を出す認証局は、ブラウザ・OS の事業者と認証局で作る CA/Browser Forum の基準（Baseline Requirements）に従います。2025 年 4 月 4 日から 11 日にかけて行われた Ballot SC-081v3 の投票では、認証局側が賛成 25・反対 0・棄権 5、ブラウザ側は Apple・Google・Microsoft・Mozilla の 4 社がすべて賛成し、次の日程が決まりました。

これは上限なので、認証局はもっと短い証明書を出せます（Let's Encrypt の 90 日がその例です）。また、組織名などの実在確認（OV・EV の審査情報）の再利用期間は、2026 年 3 月 15 日から 398 日です。ドメインの確認とは別の扱いになっています。

ドメイン認証の再利用期間も短くなるのは、なぜ影響が大きいのですか？

認証局がドメインの管理権を確認した結果を使い回せる期間も、398 日から 200 日、100 日を経て 2029 年 3 月 15 日に 10 日になるためです。証明書の更新のたびに、ほぼ毎回ドメインの確認をやり直すことになり、メールや手作業での確認は現実的でなくなります。

証明書を出す前に、認証局は申請者がそのドメインを管理していることを確かめます（DCV: Domain Control Validation）。これまでは一度確認すれば 398 日間その結果を使い回せたため、証明書の更新はほとんど書類上の手続きでした。2029 年以降は確認結果の寿命が 10 日になり、更新のたびに DNS や Web サーバーで確認に応えられる仕組みが必要になります。

ACME の自動更新はこの確認（HTTP の /.well-known/acme-challenge/ や DNS の TXT レコード）を毎回自動で行うので、影響を受けません。困るのは、確認メールを人が受け取ってクリックする運用や、DNS を手で書き換えている運用です。なお基準には、DNS に固定の TXT レコードを置いておく確認方法（§3.2.2.4.22）も加わっていますが、この方法も再利用期間は 10 日とされています。

なぜ有効期間を短くするのですか？

秘密鍵の漏えいや誤発行が起きたときに、その証明書が使われ続ける期間を短くするためです。Let's Encrypt は、短い有効期間は被害を限定し、更新の自動化を促すと説明しています。期間が短ければ、失効の仕組みに頼る場面も減ります。

証明書は、秘密鍵が盗まれても、誤って第三者に発行されても、期限までは「正しい証明書」として通用してしまいます。失効（revocation）の仕組みはありますが、Let's Encrypt は 2025 年 8 月 6 日に OCSP（失効をその都度問い合わせる仕組み）を終了し、失効情報の公開を CRL に一本化しました。理由として、OCSP では訪問者がどのサイトを見ているかを認証局が知りうるというプライバシーの問題を挙げています。

有効期間そのものが短ければ、問題のある証明書が通用する期間も短くなります。Let's Encrypt は有効期間の方針について、誤発行や鍵の漏えいによる被害を限定し、自動化を促すためと説明しています。

Let's Encrypt の証明書はどう変わりますか？

既定の 90 日は、2027 年 2 月 10 日から 64 日、2028 年 2 月 16 日から 45 日になります。2026 年 1 月 15 日からは、希望すれば約 6 日（160 時間）の証明書も使えます。期限切れの通知メールは 2025 年 6 月に、OCSP は 2025 年 8 月に終了しています。

どの変更も、その日以降に発行・更新した証明書から適用されます。64 日への切り替えに伴う失効は行わず、最後の 90 日証明書は 2027 年 5 月 11 日ごろに期限を迎える見込みだとしています。

有料の証明書や国内の認証局はどう変わりますか？

どの公的な認証局も同じ上限に従うため、有料の証明書でも年 1 回の更新はできなくなります。たとえば JPRS は 2026 年 2 月 18 日以降の発行分から、有効期限を「発行月の 5 か月後の月末まで」に短縮し、ACME 対応版への一本化も予定していると案内しています。

上限は Baseline Requirements で決まっているため、有料・無料や、DV・OV・EV の種類に関わらず、公的に信頼される証明書すべてに及びます。「有料の 1 年証明書を毎年手で入れ替える」運用は、2026 年 3 月 15 日以降の発行分から成り立ちません。

国内の例として、JPRS は 2026 年 2 月 18 日以降に発行する証明書から、有効期限を「証明書発行日の属する月の 5 カ月後の月末まで」（従来は 1 年後の月末まで）に変更しました。ACME 対応版の有効期間は、2026 年 6 月 17 日以降の発行分で 90 日から 88 日に変えています。今後はサービスを ACME 対応版だけで提供する予定で、時期は決まり次第知らせるとしています。利用中の認証局やレンタルサーバーの案内を確認してください。

自動更新はどう設定すればいいですか？

ACME（RFC 8555）に対応したクライアントやサーバーで、更新を定期実行にします。Caddy は標準で自動、nginx や Apache なら certbot などを使います。更新の時期は残り日数の固定値ではなく、有効期間の約 3 分の 2 が過ぎた時点か、認証局が指示する時期（ARI）にします。

# Caddyfile — ドメイン名を書くだけで、取得・更新・HTTPS へのリダイレクトまで自動
example.com {
	root * /var/www/html
	file_server
}

# 更新が自動で動く設定になっているか（パッケージ版 certbot は systemd タイマーか cron で動く）
systemctl list-timers | grep -i certbot

# 実際には発行せずに、更新の手順が通るかだけを試す
sudo certbot renew --dry-run

# Let's Encrypt の短い証明書（約 6 日）を選ぶ場合（certbot 4.0 以降）
sudo certbot certonly --preferred-profile shortlived -d example.com

更新のタイミングは「残り日数の固定値」で決めない

90 日証明書の時代は「60 日ごとに更新」「残り 30 日で更新」という設定がよく使われました。Let's Encrypt は、45 日証明書では 60 日ごとの更新では間に合わないとし、有効期間の約 3 分の 2 が過ぎた時点で更新するよう勧めています。スクリプトや cron に「60」「80」「83」のような日数が直書きされていないか確認してください。

さらに確実なのは、ARI（ACME Renewal Information、RFC 9773）に対応したクライアントを使うことです。認証局が「いつ更新すべきか」を伝えるので、有効期間が変わっても、認証局の都合で前倒しの更新が必要になっても、クライアントが自分で合わせます。

TLS 1.0・1.1 は無効にすべきですか？ TLS 1.3 は必要ですか？

TLS 1.0・1.1 は 2021 年の RFC 8996 で使用禁止とされ、主要ブラウザも既に使いません。サーバー側でも無効にし、TLS 1.2 と 1.3 だけを有効にしてください。TLS 1.3 はハンドシェイクが 1 往復少なく、古い暗号方式を含まないため、対応しておくのが望ましい状態です。

# nginx — TLS 1.2 と 1.3 だけを有効にする
ssl_protocols TLSv1.2 TLSv1.3;

TLS 1.0・1.1 を受け付けたままでも、最近のブラウザはそれを使わないので、直ちに訪問者が危険にさらされるわけではありません。ただし古い方式を残しておく理由はほとんど無く、RFC 8996 もサーバー・クライアントの双方に無効化を求めています。

サイト総合診断は、証明書と TLS をどう判定していますか？

証明書は、残り日数を有効期間に対する割合で判定します。期限切れ・ホスト名の不一致・自己署名・検証エラーは「問題あり」です。TLS は、1.3 で接続でき、別の接続で試した 1.0・1.1 が拒否されれば合格、1.2 止まりや 1.0・1.1 を受け付ける場合は「要改善」としています。

以前は「残り 14 日未満で問題あり・30 日未満で要改善」という固定のしきい値でした。しかしこれでは、Let's Encrypt の 6 日証明書は発行直後から常に「問題あり」になり、45〜64 日の証明書も通常の更新サイクルの中で「要改善」が出続けます。正しく自動更新しているサイトほど減点されるので、有効期間（L 日）に対する割合に変えました。

• 問題ありになるのは、期限切れ・上の表のしきい値未満・ホスト名が証明書と一致しない・自己署名・認証局までたどれない（検証エラー）のいずれかです。HTTPS で配信されていない場合も問題ありです
• 有効期間は証明書の notBefore から notAfter まで（両端を含む）で計算します。日付を読めなかった場合は、従来の 14 日・30 日で判定します
• 有効期間が 100 日を超える公的な証明書には、短縮の日程と自動更新を案内します。有効期間が、発行日（notBefore で推定）に対する上限を 1 日より多く超えている場合は、認証局に確認するよう補足します。判定（合否）は変えません

TLS のバージョンは、通常の接続（TLS 1.2 以上）で合意したバージョンに加えて、TLS 1.0・1.1 だけを許した接続を別に 1 回試して判定します。HTTP のリクエストは送らず、ハンドシェイクだけです。

自分のサイトの証明書の有効期限は、どう確認しますか？

ブラウザならアドレスバーの鍵アイコンから証明書の詳細を開き、有効期間の開始日と終了日を見ます。コマンドなら openssl s_client で接続し、openssl x509 -noout -dates で日付を表示できます。発行者と有効期間の長さを見れば、自動更新の証明書かどうかの見当もつきます。

# 有効期間（notBefore / notAfter）と発行者を表示する
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

# 出力例
# notBefore=Oct  1 00:00:00 2026 GMT
# notAfter=Dec 29 23:59:59 2026 GMT
# issuer=C = US, O = Let's Encrypt, CN = R12

# TLS 1.3 で接続できるか
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

notBefore と notAfter の差が、その証明書の有効期間です。約 90 日なら ACME の自動更新である可能性が高く、約 1 年なら手作業で入れている可能性があります。手作業なら、2026 年 3 月 15 日以降の更新から有効期間が 200 日以下になるので、その前に自動化を検討してください。

HTTPS 化そのものがまだなら HTTP から HTTPS へのリダイレクト、HTTPS を強制する設定は HSTS で解説しています。サイト総合診断のセキュリティの項目では、証明書の残り日数と有効期間、TLS のバージョンをまとめて確認できます。