SSL証明書の有効期間が200日・100日・47日に短縮｜スケジュールと対策

2025年4月、CA/Browserフォーラムで投票 SC-081 が可決され、ブラウザに信頼される公開TLS（SSL）サーバ証明書の最大有効期間が段階的に短縮されることが決まりました。最終的には47日になり、証明書の更新は年1回の作業から「毎月の自動処理」に変わります。

スケジュール

有効期間の上限は発行日で決まります。すでに発行済みの証明書が途中で短くなることはありません。

何が変わるのか

• 更新回数が増える：47日になると、余裕を持たせて年に8〜12回程度の更新が必要になります。
• ドメイン認証もやり直しが増える：2029年以降、DCVの再利用は10日までになるため、更新のたびに認証がほぼ必要になります。DNSやHTTPによる認証の自動化が前提です。
• 手作業の更新は事故のもと：更新漏れ、Webサーバのリロード忘れ、冗長構成の一部ノードだけ古いまま、といった事故が起きやすくなります。

今からやっておくこと

1. 証明書の棚卸し：どのホスト・どの機器で、どのCAの証明書を使っているかを洗い出します。
2. ACMEによる自動更新：certbot・lego・acme.sh などのACMEクライアント、またはクラウド・CDNのマネージド証明書に移行します。
3. 配布とリロードの自動化：更新した証明書をすべてのサーバに配り、リロードまでを一連の処理にします。Ansibleなら handler と meta: flush_handlers で確実に反映できます。
4. 更新結果の確認：自動化しても「実際に新しい証明書が配信されているか」を外部から確認する仕組みが必要です。
5. 監視しきい値の見直し：「残り30日で警告」のような固定日数は、47日の証明書では常に警告になってしまいます。有効期間に対する残り割合（例：1/3未満で更新）で判定するのがおすすめです。

SSLチェッカーでの確認

SSLチェッカーは、ホスト名が解決される全IPアドレスに接続し、残り割合による判定、サーバ間の証明書の不一致、前回からの更新の有無を表示します。APIを使えば、更新処理の最後に「全サーバに新しい証明書が反映されたか」を自動で確認できます。

curl -fsS "https://sslcheck.nakayumc.com/api/v1/check?host=www.example.com&min_days=30&nocache=1" | jq -e '.result == "pass"'

参考

• CA/Browser Forum, Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
• CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates