CA/Browser Forum の新ルール：2026年から始まる SSL 証明書の有効期限の段階的短縮化。
最終的には 2029年に 47 日 という極めて短い有効期間になる。これまで「年 1 回更新」で済んでたやつが、近い未来「月複数回更新」になる可能性がある。
正直、手動管理では確実に破綻する。この記事は、「うちのチーム、どう対応すればいい？」という実装判断を書いておく。
タイムラインの全貌
CA/Browser Forum が定めた段階的短縮化
| 時期 | 有効期限 | 管理頻度目安 | 影響度 |
|---|---|---|---|
| 現在（2026年3月まで） | 398 日 | 年1回更新 | 低 |
| 2026年3月15日～ | 200 日 | 年1～2回更新 | 中 |
| 2027年3月15日～ | 100 日 | 年3～4回更新 | 高 |
| 2029年3月15日～ | 47 日 | 月複数回更新 | 超高 |
2029年の恐怖：47日制限とは
47日という期間は、現在の管理方法では実質的に自動化が必須を意味する。
なぜなら：
- 人間が「そろそろ更新しようか」と判断→実行 → 検証 → デプロイ
- この一連が確実に完了するまでに、確実に 1～2週間かかる
- 47日 - 2週間 = 残り約5週間の余裕
- その間に他の作業が入ると、簡単に「あ、更新忘れた」になる
問題の本質：「手動管理の破綻」
ケース 1：小規模チーム（1～3人）
現状：
- 証明書が 1～3個
- 年1回のリマインダーで更新
2029年以降：
- 証明書が同じ数でも、更新頻度が 約 9 倍
- 月に複数回、毎回「更新→検証→デプロイ」の手作業
- 誰か 1人が退職したら、知識が失われてヤバい
結果：確実に誰かが忘れる → SSL エラー → サービス停止 → 信用喪失
ケース 2：中規模チーム（複数サーバー、複数ドメイン）
現状：
- 証明書が 10～20 個
- スプレッドシートで管理
2029年以降：
- 月に 10～20 個 × 複数回の更新作業
- 手作業では追いつかない
- ミスの確率が指数関数的に増加
結果：管理が混乱 → 本番環境で SSL エラー → 顧客影響
ケース 3：大規模企業（複数部門、複数国）
現状：
- 証明書が 100 個超
- 既に何かしらの管理システムで対応
2029年以降：
- 手動ステップが多いと管理システム自体がボトルネック
- 完全自動化への移行が必須
解決策：ACME プロトコルによる完全自動化
根本的な対応：自動更新の導入
2029年の 47 日制限に耐えられる唯一の方法は、ACME プロトコルを使った完全自動更新。
ACME とは：
- Automated Certificate Management Environment
- Let's Encrypt が提唱した、証明書の自動更新プロトコル
- OpenSSL コマンドで
certbotを使うことが最も一般的
実装方法：Certbot を使った自動更新
ステップ 1：Certbot のインストール
# Ubuntu/Debian sudo apt-get install certbot python3-certbot-nginx # CentOS/RHEL sudo yum install certbot python3-certbot-nginx # macOS brew install certbot
ステップ 2：証明書の自動更新設定
# 証明書を取得（初回） sudo certbot certonly --nginx -d example.com -d www.example.com # 自動更新の動作確認 sudo certbot renew --dry-run
ステップ 3：cron で定期実行
# root ユーザーで crontab を編集 sudo crontab -e # 以下を追加（毎日 2:30 に更新試行） 30 2 * * * /usr/bin/certbot renew --quiet && systemctl reload nginx
この設定で：
- 毎日自動で更新チェック
- 更新が必要なら自動実行
- Nginx をリロード
- すべて無人で完結
メジャーな証明書発行者の ACME 対応
| CA | ACME サポート | URL | 推奨度 |
|---|---|---|---|
| Let's Encrypt | ✅ | https://letsencrypt.org | ⭐⭐⭐⭐⭐ |
| GlobalSign | ✅ | ACME API あり | ⭐⭐⭐⭐ |
| DigiCert | ✅ | ACME API あり | ⭐⭐⭐⭐ |
| Sectigo | ✅ | ACME API あり | ⭐⭐⭐⭐ |
推奨：Let's Encrypt でテストしてから、有料 CA に移行。
段階的な導入ロードマップ
Phase 1：現状把握（今月）
- ドメイン名 / 発行元 CA / 有効期限 / 更新予定日
- 誰が更新してるのか / どのサーバーが対象か / 更新後の検証手順は
Phase 2：Let's Encrypt で試験運用（1～2ヶ月）
- インストール / 自動更新の動作確認 / 運用手順の整理
- Let's Encrypt の証明書を取得 / 1ヶ月運用してみる / 特に問題ないか確認
Phase 3：段階的な本番環境への展開（2～4ヶ月）
- 更新スクリプトの改善 / 監視・アラート設定 / トラブル対応の経験値を貯める
- 100日制限への対応が必須になる前に
Phase 4：完全自動化（2027年まで）
- ACME ベースの統一管理 / 中央管理ダッシュボード / 異常時のアラート設定
実装時の注意点
1. Let's Encrypt のレート制限
Let's Encrypt は無料だが、制限がある：
- 週あたり 50 個の新規証明書
- 1 ドメインあたり 5 個/週
複数ドメインで同時に導入すると、レート制限に引っかかる可能性がある。段階的導入が大事。
2. DNS 検証 vs HTTP 検証
Certbot の検証方法は 2 種類：
| 方法 | 特徴 | 推奨度 |
|---|---|---|
| HTTP 検証 | .well-known フォルダで検証。シンプル |
⭐⭐⭐⭐⭐ |
| DNS 検証 | DNS レコード追加で検証。ワイルドカード対応 | ⭐⭐⭐⭐ |
通常は HTTP 検証で十分。DNS 検証が必要なのはワイルドカード証明書の場合。
3. 更新スクリプトのテスト
本番環境を止めないために：
sudo certbot renew --dry-run --non-interactive # このコマンドを cron で定期実行して # 「更新が失敗していないか」を事前に検知する
4. 監視・アラート設定
ACME 自動化しても「更新に失敗する」可能性はある。例：
- DNS が一時的に応答しない
- サーバーのディスク容量が満杯
- スクリプトのバグ
対策：
30 2 * * * /usr/bin/certbot renew --quiet || \
mail -s "SSL renewal failed" admin@example.com
コスト評価
導入前（手動管理）
| 項目 | 金額 | 説明 |
|---|---|---|
| 証明書購入費 | 月 0～10万円 | CA による |
| 人件費（更新作業） | 月 2～5万円 | 年1回なら月割り |
| 合計 | 月 2～15万円 |
導入後（ACME 自動化）
| 項目 | 金額 | 説明 |
|---|---|---|
| 証明書購入費 | 月 0～10万円 | CA による（Let's Encrypt なら ¥0） |
| 人件費（初期構築） | 50～100万円 | 1 回限り |
| 人件費（運用・監視） | 月 1～3万円 | 異常時対応のみ |
| 合計 | 初期 50～100万円 + 月 1～13万円 |
ROI：
- 初期投資が回収できるのは、約 3～6ヶ月
- 5 年運用なら 年平均で 15～20万円削減
実装チェックリスト
今月やること
来月やること
3ヶ月以内にやること
2027年3月までにやること
最後に：なぜこんなことになるのか？
CA/Browser Forum が証明書有効期限を短縮化した背景：
- セキュリティ向上 - 秘密鍵の露出リスクを早期に低減
- 自動化の推進 - 手動管理では対応できないレベルに引き上げることで、業界全体の自動化を加速
- 脆弱性対応の高速化 - 有効期限が短ければ、脆弱性検出時に「全サーバーの置き換え」が現実的
つまり、業界全体を「手動管理」から「自動化」へ強制的にシフトさせるための施策。
2029年の 47日制限は、もはや「手動では対応不可」という業界の合意。
早めに自動化しておけば、慌てずに対応できる。逆に、2028年になって「あ、対応しなきゃ」って思っても、もう手遅れ。
今から準備しておこう。