SSL証明書の有効期間が「さらに短く」なる。90日ルールの衝撃と対応策
SSL証明書の有効期間は、ここ数年で静かに、しかし確実に短縮され続けています。そして今、業界全体が次なる大きな転換点、「90日有効期間の義務化」へと向かおうとしています。これは単なる技術的な仕様変更ではありません。**すべてのWebサイト運営者、証明書発行企業、そしてエンドユーザーにとって根本的な運用の見直しを迫られる“ルールの変化”**です。
本記事では、この動向の背景、予測される影響、そして今から取るべき対応について解説します。
これまでの流れ：有効期間はなぜ短縮されてきたか？
かつてSSL証明書は最長5年間の有効期間を誇っていました。それが、2018年には3年→2年に、2020年9月には最大1年（398日）へと短縮されました。
これは、以下の背景によるものです：
- セキュリティ強化
長期間の証明書は鍵が漏洩した場合のリスクが高まる - 証明書の誤発行対策
短期で更新されれば、誤発行の修正も早くなる - インフラ更新の促進
定期的な更新が古い技術の使い回しを防ぐ
このような目的から、有効期間は着実に短縮されてきました。
次に来るのは「90日」— AppleとGoogleが示す方向性
2023年、AppleはSafariやiOSで受け入れるSSL証明書の有効期間について「将来的に90日に短縮する方針」を明言し、Google Chromeも同調する意向を示しました。
現在、AppleやGoogleはCA/Bフォーラム（証明書業界の標準化団体）において有効期間90日制限の議論を進めており、実施は早ければ2025年内〜2026年初頭にも開始される見込みです。
つまり、強制的に「3ヶ月ごとのSSL更新」が必要になる時代が来ようとしています。
なぜ「90日」に？その理由と目的
短縮の狙いは一貫して「セキュリティの強化」です。特に以下の観点が重要です：
- 鍵漏洩リスクの抑制
→ 90日なら仮に秘密鍵が漏洩しても影響は最小限 - 証明書の不正使用防止
→ 不正取得の証明書も短期間で期限切れにできる - オートメーションの促進
→ 頻繁な更新が手動運用を困難にし、自動化を強制する
実際に何が変わるのか？
仮に90日ルールが正式に施行されれば、以下のような変化が発生します：
現在の運用
- 年1回の更新で十分（1年証明書）
変更後の運用
- 年4回以上の更新が必要
- ドメイン認証（DCV）も3ヶ月ごとに実施
- サーバー設定や証明書の自動再デプロイが必須
- 作業漏れ＝即サイト停止のリスク
一度でも更新作業を忘れれば、証明書失効→ブラウザ警告表示→サイト離脱・信用失墜という悪夢が現実となります。
影響を受けるのは「誰か」ではなく「全員」
これはSSL証明書の契約者だけの話ではありません。影響は以下の全プレイヤーに及びます：
| 対象者 | 受ける影響 |
|---|---|
| Webサイト運営者 | 証明書の更新作業が頻繁に。自動化しないと対応不能に |
| システム開発者 | 証明書管理・更新・再起動の仕組みをコードに組み込む必要 |
| 企業の情シス部門 | 内部WebアプリケーションやVPNなども含めた全体対応が必要 |
| SSL販売代理店 | 顧客サポートや更新リマインドの負荷が数倍に増加 |
今からできる対応策
以下は今から準備すべき現実的なアクションです：
ACMEプロトコルによる自動更新の導入
Let’s EncryptやSectigo、DigiCertなどが提供するACME対応証明書サービスを利用し、証明書の自動取得・更新を行う仕組みの構築が最優先です。
DevOps・CI/CD連携
証明書更新→Webサーバ再起動→構成反映のフローを自動化する必要があります。
証明書のライフサイクル管理体制の見直し
スプレッドシートでの更新管理は限界。証明書の一元管理ツールや**APIベースの証明書サービス（CaaS）**の導入を検討すべきです。
「1年」はもう長すぎる時代へ
一見、年1回のSSL更新など些細な運用作業に思えるかもしれません。しかし、「それが年4回になった」と考えると話は変わってきます。しかもその作業はセキュリティに直結し、失敗すれば即・信用を失うものです。
今、SSL証明書は“取得して終わり”ではなく、“管理し続けるもの”へと進化しています。変化のスピードは速く、待ってくれません。
最後に：あなたの証明書は、準備できていますか？
この制度変更は「来るかもしれない未来」ではなく、既に規格として議論され、実現に向けて動いている現実です。ギリギリになって慌てる前に、今すぐ証明書運用の棚卸しを行いましょう。
「SSLは設定して終わり」の時代はもう終わりました。これからは「更新し続ける覚悟」が求められるのです。
コメント