【重要】TLS/SSL証明書の有効期間短縮（199日運用）とACME自動更新の推奨
CA/Browser Forum の業界ルール改定により、パブリック TLS/SSL サーバ証明書の最大有効期間は段階的に短縮されます。最終的に 47 日まで縮むため、これまで以上に証明書の更新（再発行・サーバへの差し替え）頻度が大幅に増加します。本ページでは、有効期間短縮スケジュールと、47 日ルール時代の運用設計指針について解説します。
- 2029 年から最大有効期間は 47 日。年 8 回以上の更新運用が前提に
- 複数年プランは「契約期間」を延ばすだけで、証明書自体は短サイクル更新が必要
- 当社推奨は ACME プロトコルによる自動更新。標準仕様（IETF）で長期運用に強い
📅 有効期間短縮スケジュール
| 時期 | 最大有効期間 | 年間更新回数 | 運用への影響 |
|---|---|---|---|
| 〜 2026 年 3 月中旬 | 398 日 | 約 1 回 | 年 1 回の更新運用 |
| 2026 年 3 月中旬〜 | 200 日（実務上 199 日） | 約 2 回 | 半年に 1 回の更新 |
| 2027 年 3 月中旬〜 | 100 日 | 約 4 回 | 四半期ごとの更新 |
| 2029 年 3 月中旬〜 | 47 日 | 約 8 回 | ほぼ毎月の更新運用 |
2026 年 3 月以降は最大 200 日ですが、運用上の安全マージンを取って 199 日として扱う認証局やクライアントが多くあります。期限切れの 1 日前ではなく、確実に更新を完了させる設計です。
特に最終段階の 47 日になると、実務上はほぼ毎月の更新運用が前提となります。10 枚の証明書を管理している組織では、年間 80 回以上の更新作業が発生する計算です。
💰 複数年プラン／サブスクリプションについて
「契約は複数年でまとめたい」というニーズに対し、複数年プラン（サブスクリプション）が用意されている認証局もあります。しかし、ここで重要な誤解があります。
複数年プランは「契約・請求」をまとめられる仕組みであり、証明書そのものの有効期間が延びるわけではありません。契約期間が 2 年でも 10 年でも、証明書は業界ルール通りの短サイクル（最終的に 47 日）で再発行が必要です。
複数年プランで起きること
- 契約期間中、業界ルール通りに証明書が短サイクルで再発行される
- そのたびに新しい証明書をサーバへ置き換えて反映する必要がある
- つまり「複数年契約 = 更新作業が省ける」ではない
このため当社（SSL ストア / FujiSSL）では、複数年プランを推奨していません。更新頻度が上がるほど、手動運用での更新漏れや差し替えミスのリスクが現実的に高まります。「契約だけ長く」して運用は短サイクルという構造は、リスクの先送りになりかねません。
🛠 ACME を推奨する理由
証明書の更新運用を自動化する方法には、複数のアプローチがあります。
更新自動化のアプローチ比較
| 方式 | 仕組み | 長期運用での課題 |
|---|---|---|
| ACME プロトコル | IETF 標準（RFC 8555）の自動化プロトコル | 標準準拠で長期安定 |
| 独自 API 連携 | 認証局独自の API を直接呼び出す実装 | API 仕様変更時の改修コスト |
| 更新ツールの独自実装 | 社内スクリプト等で発行・反映を組む | 属人化・保守負担の累積 |
| 管理画面操作の自動化（RPA 等） | ブラウザ自動操作で更新作業を再現 | UI 変更で簡単に壊れる |
独自実装や RPA 等は仕組みが個別最適になりやすく、環境差や仕様変更の影響を受けやすいため、長期運用では保守負担や更新失敗リスクが増える傾向があります。
当社では、こうした 「ACME 以外の手段で更新を頑張る運用」よりも、ACME プロトコルによる自動更新を推奨します。ACME は、証明書の発行 〜 更新 〜 反映までを自動化することを前提に設計された標準化された公式手段（IETF RFC 8555）であり、有効期間短縮（199 日 → 100 日 → 47 日）に伴って更新頻度が増えるほど、運用の安定性と再現性の面で有利になります。
ACME が短サイクル更新に強い 4 つのポイント
-
標準プロトコルで長期安定
IETF 標準のため、特定の独自仕様に依存せず、認証局を乗り換えても同じクライアントで運用継続可能。仕様変更の影響を受けにくく、長期運用で壊れにくい構成。
-
頻度増加にスケールしやすい
更新頻度が上がる局面（199 日 → 100 日 → 47 日）でも、cron / systemd timer の頻度を変えるだけで対応可能。手動運用のように「人手」がボトルネックにならない。
-
反映まで含めて自動化できる
更新の自動化は「発行」だけでなく、サーバへの反映（差し替え・再読み込み）まで含めて設計できます。certbot / acme.sh の各種プラグインや Caddy / Traefik の組込み機能で、サービス無停止での切替が標準実装されています。
-
ヒューマンエラーの排除
手動運用で起きがちな更新漏れ・コモンネームのタイプミス・中間証明書の配置忘れ・リロード忘れなどのリスクを、仕組みで排除できます。
📋 47 日ルール時代の運用設計指針
有効期間短縮の影響を受けないためには、更新を仕組み化（自動化）することが必須です。今後の短サイクル更新を見据え、可能な限り早い段階で ACME による自動更新への移行を推奨します。
推奨される対応ステップ
-
現状の証明書運用を棚卸し
管理している証明書の枚数・有効期限・サーバ構成・担当者を一覧化。47 日ルール導入後の作業量を試算します。
-
ACME 対応認証局への切替を検討
FujiSSL / Sectigo など、ACME 対応認証局への移行を検討。既存証明書は有効期限まで継続使用可能なため、サービス停止リスクなく段階移行できます。
-
ACME クライアントの選定・テスト
サーバ環境に応じて certbot / acme.sh / win-acme / cert-manager 等を選定。テストドメインで動作確認します。
-
本番ドメインへ段階展開
テスト成功後、本番ドメインへ展開。証明書の自動更新・自動反映・監視通知まで含めた運用を確立します。
🏢 FujiSSL の ACME 対応について
当グループ運営の FujiSSL では、ACME プロトコルによる自動更新に完全対応しています。
対応ラインナップ
- FujiSSL 自動更新（ACME） — DV / OV / EV / ワイルドカード対応
- Sectigo 自動更新（ACME） — DV / OV / ワイルドカード対応
ACME 自動更新は DV 証明書では普及していますが、OV（企業認証）証明書まで ACME 対応している商用認証局は世界でもごく少数です。FujiSSL は OV ACME に対応しており、法人サイト・企業 EC でも完全自動運用が可能です。
🤝 運用設計のご相談
ACME 導入時の以下のポイントについて、運用設計のご相談を承っています。
- 認証方式の選定 — HTTP-01 / DNS-01 / TLS-ALPN-01 のどれが適切か
- 更新後の自動反映 — サーバ・ロードバランサ・CDN への差し替え設計
- 監視・通知の設計 — 更新失敗時の検知・アラート構成
- 段階移行プラン — 既存証明書からの世代交代スケジュール
運用設計を相談する →
FujiSSL ACME を申し込む →
📚 関連ページ
- ACME 自動更新ガイド — プロトコル詳細・動作原理
- ACME 対応証明書一覧 — 当店取扱の ACME 対応版
- 手動運用から ACME への切替え手順 — 移行ステップ詳細
- ACME クライアントの選び方 — 環境別の推奨クライアント