SSL証明書の有効期限短縮ショック…手動更新の限界と自動化への道
先日、インフラ担当の若手から「あれ、この証明書、前更新したの最近じゃなかったでしたっけ？」とボヤかれまして。確かに、昔は2年や3年有効なのが当たり前だったSSL/TLS証明書ですが、ここ最近はすっかり短命になりましたね。
そして今回、ブラウザベンダー界隈からさらに胃の痛くなるようなロードマップが聞こえてきました。どうやら現場の気合いや、スプレッドシートの手動管理では乗り切れないフェーズに突入したようです。
現在： 最大有効期間 398日
2026年3月15日以降： 200日に短縮
2027年3月15日以降： 100日に短縮
2029年3月15日以降： 47日に短縮（審査情報の再利用も10日へ劇的に制限）
いよいよ来る、SSL証明書「200日」時代
Googleをはじめとするブラウザベンダーが主導する形で、セキュリティ向上のためにSSL証明書の有効期限短縮が着々と進んでいます。
CA/ブラウザフォーラムにおいて、以下のように段階的な短縮方針が正式に可決されました。
| 適用日 | 最大有効期間 | ドメイン審査情報 再利用期間 |
組織認証情報 再利用期間 |
|---|---|---|---|
| 現在 | 398日 | 398日 | 825日 |
| 2026年3月15日以降 | 200日 | 200日 | 398日 |
| 2027年3月15日以降 | 100日 | 100日 | 398日 |
| 2029年3月15日以降 | 47日 | 10日 | 398日 |
一気に短くなる印象ですね。2029年には47日…約1.5ヶ月ごとですよ？四半期のサイクルより短いうえに、ドメイン審査情報の再利用期間も10日になるため、これまでの「ついでに更新」感覚では全然通らなくなります。ちょっと他の大きなプロジェクトにかまけていたり、メンバーが長めの休暇を取ったりしていたら、あっという間に期限がやってきます。これはインフラチームにとって笑えない冗談です。
プレイングマネージャー視点で見る「本当のコスト」
この期限短縮、技術的な変化というより、実は「運用コストとリスクの問題」なんですよね。私もプレイングマネージャーとして部門の予算や工数を見る立場にあるので、ここはシビアに考えざるを得ません。手動更新を続けた場合の影響を整理してみましょう。
| 項目 | 現場と管理のリアルな影響 |
|---|---|
| 証明書費用 | 購入総額自体には大きな変動はないと見込んでいます。（経理へは「予算は維持できます」と説明はつきます） |
| 管理工数 | 問題はここです。年1回の更新が年8回以上になる計算です。CSD作成、申請、審査対応、サーバーへのインストール、再起動…それぞれの作業時間は短くても「チリツモ」で人件費が急増します。現場の時間を奪うのは大きな痛手です。 |
| 失効リスク | 更新頻度が上がるということは、単純に「ヒューマンエラー（更新作業の失念）」の確率が跳ね上がるということです。証明書切れによるサイト閉鎖やサービス停止になった場合、始末書どころか顧客からの信用失墜という取り返しのつかない事態になります。 |
「気合い」を捨ててACMEで自動化しよう
結論から言うと、もう「カレンダーに予定を入れて手動更新で頑張る」という選択肢は捨てた方がいいです。現場の疲弊を招くだけですし、何より事故の元です。手動管理によるコスト増とリスクを回避するためには、以下のような体制への移行が必須です。
- ACMEプロトコルの活用： 証明書の発行からインストール、更新までを自動化する標準規約ですね。Let's Encryptなどでお馴染みですが、最近は商用証明書でもACME対応が広がっています。
- 管理ツールの刷新： 複数サーバーの証明書を一元管理し、ダッシュボードで状況を可視化できるツールの導入を検討・構築します。
- 運用フローの見直し： 実はここが一番重要かもしれません。「期限が来たら人が動く」という旧来のフローから、「自動更新システムが正常に動いているかを監視する（エラー時のみ人が介入する）」というモダンな運用へのパラダイムシフトです。
インフラの自動化は組む時の面白さもありますが、これは何よりも「ビジネスの継続性を守り、チームの疲弊を防ぐための必須投資」です。
「いや、今のままでも気合いでいけるだろう」と先延ばしにするより、いまの時期から「証明書の短命化によって今の運用では確実に破綻します」と上を説得して、自動化への工数と予算を確保しておくことを強くお勧めします。後で泣きを見るのは現場のエンジニアや私たちですからね。
さて、私も明日の定例で提案するための説得資料でも作りますか。みなさんも早めの準備を。