TLS証明書の有効期限が47日に短縮|更新頻度増加と自動化対応策
2025年4月、電子証明書のガイドラインを策定するCA/Browserフォーラム(The Certification Authority/Browser Forum)において、SSL/TLSサーバー証明書(以下、証明書)の最大有効期間を段階的に短縮し、最終的に47日とする決定がなされました。
この決定は、証明書の更新頻度を大幅に増加させ、企業のインフラ運用に大きな影響を与えます。これまで証明書管理を「手動」で行ってきた多くの企業にとって、この変化は無視できない運用の転換点となります。
実際、お客様からも「証明書の更新が大変になるのでは」というお問い合わせをいただく機会が増えてまいりました。
本記事では、現場のネットワークエンジニアの視点から、この変化がもたらす課題と、その解決策であるACMEプロトコルによる自動化の必然性について、2026年現在の最新情報に基づいて解説します。
| ●結論:TLS証明書の有効期限は段階的に短縮され、最短47日になる ・2026年3月15日以降:最大200日 ・2027年以降:最大100日 ・2029年以降:最大47日 |
【本記事の想定対象】
・証明書の有効期限短縮を見据え、今後の手動更新運用に課題を感じている環境
・FortiGate等のNW機器において、ACMEによる自動更新を実装したい
・2026年3月の制度変更に向け、インフラ運用の自動化を検討中の担当者
- 1. TLS証明書の有効期限が短縮される理由とスケジュール
- 1.1. なぜ短縮されるのか?(セキュリティ的背景)
- 1.2. 段階的な短縮スケジュール:直近の期限は2026年3月
- 2. 有効期間短縮がもたらす実務への影響:更新頻度8倍への対応課題
- 2.1. 運用負荷の具体的な試算
- 3. 解決の鍵「ACMEプロトコル」とは何か
- 3.1. ACMEプロトコルによる証明書更新の仕組み
- 3.2. ACMEにおけるチャレンジ方式(HTTP-01 / DNS-01)
- 4. ネットワークエンジニアの視点:アプライアンス製品の対応と課題
- 4.1. 現場の懸念:アプライアンス製品のACME対応
- 4.2. FortiGateのACME対応状況と技術的制約
- 4.3. ACME非対応機器への現実的な回避策
- 5. まとめ:2026年以降、インフラ運用に求められる備え
TLS証明書の有効期限が短縮される理由とスケジュール
なぜ短縮されるのか?(セキュリティ的背景)
証明書の有効期間が短縮される最大の理由は、インターネット全体のセキュリティ水準の向上にあります。有効期間が短くなることで、万が一、証明書の秘密鍵が漏洩した場合でも、その証明書が悪用される期間を最小限に抑えることができます。
また、暗号技術や攻撃手法が急速に進化する現代において、長期間有効な証明書を使い続けること自体がリスクになりつつあります。この短縮化は、証明書のライフサイクルを短く保ち、常に最新のセキュリティ基準を適用させることを目的としています。
段階的な短縮スケジュール:直近の期限は2026年3月
CA/Browserフォーラムの決定に基づき、証明書の最大有効期間は以下のスケジュールで段階的に短縮されます。
| 証明書発行日 | 最大有効期間 | 備考 |
|---|---|---|
| 〜 2026年3月14日 | 398日 | 現行の「約13カ月」ルール |
| 2026年3月15日 〜 2027年3月14日 | 200日 | まもなく到来する最初の短縮ステップ |
| 2027年3月15日 〜 2029年3月14日 | 100日 | 約3カ月に一度の更新が必要に |
| 2029年3月15日 〜 | 47日 | 約1.5カ月に一度の更新が必要に |
ポイントは、2026年3月15日です。この日を境に、これまで年1回で済んでいた更新作業が約7カ月に1回(200日)へと短縮されます。この最初のステップへの対応が、2026年のインフラ運用における喫緊の課題となります。
有効期間短縮がもたらす実務への影響:更新頻度8倍への対応課題
現在、多くの企業では、証明書の有効期限が近づくと担当者が手動でCSR(Certificate Signing Request)を作成し、CA(認証局)に申請、発行された証明書を各サーバーやネットワーク機器にインストールするという作業を行っています。
この手動での更新作業は、有効期間が398日であったとしても以下のようなリスクを常に伴っていました。
1. サービス停止リスク: 更新漏れや、設定ミスによるサービス停止。
2. 人的ミス: 秘密鍵の取り扱いミス、誤った証明書のインストール。
3. 属人化: 更新手順が担当者の知識や経験に依存し、手順書が形骸化。
運用負荷の具体的な試算
有効期間が最終的に47日に短縮されると、証明書の更新頻度は従来の約8倍に増加します。
これは現場のネットワークエンジニアが直面する、極めて現実的な課題です。証明書が100枚ある企業の場合、単純計算で年間800回以上の更新作業が発生する可能性があり、人手に頼った管理・更新は現実的な選択肢ではなくなります。
この運用負荷の増大は、単なるコスト増に留まらず、本来注力すべきセキュリティ対策やDX推進といった戦略的な業務を圧迫する要因となりかねません。この課題を解決するためには、証明書管理の自動化が不可避となります。
解決の鍵「ACMEプロトコル」とは何か
ACMEプロトコルによる証明書更新の仕組み
証明書更新の頻度が大幅に増加する中で、その運用負荷を軽減するための答えとなるのが、ACME(Automatic Certificate Management Environment)プロトコルです。ACMEは、証明書の発行、更新、失効といったライフサイクル全体を自動化するために設計された標準プロトコルであり、Let’s Encryptをはじめとする多くのCAで採用されています。
ACMEにおけるチャレンジ方式(HTTP-01 / DNS-01)
ACMEプロトコルを利用する際、証明書が証明しようとしているドメイン名が正しい所有者によって管理されていることを検証するために「チャレンジ」が使用されます。主なチャレンジ方式は以下の2つです。
| チャレンジ方式 | 検証方法 | メリット | デメリット |
|---|---|---|---|
| HTTP-01 | Webサーバーの特定パスにファイルを配置し、CAがHTTP(80)でアクセスして検証。 | 導入が比較的容易。certbotなど自動化ツールが豊富。 | ワイルドカード証明書は取得不可。Webサーバーがパブリックに公開されている必要がある。 |
| DNS-01 | DNSのTXTレコードに特定の値を書き込み、CAがDNSをクエリして検証。 | ワイルドカード証明書が取得可能。Webサーバーの公開は不要。 | 導入ハードルが高い。DNSサーバーへのAPI連携(自動アップデート処理)が必要。 |
ネットワークエンジニアの視点から見ると、ワイルドカード証明書の取得が可能であるDNS-01チャレンジは、サブドメインが多い環境や、Webサーバーを外部に公開できないプライベート環境において、非常に強力な選択肢となります。しかし、DNSサーバーの種類によってAPI連携の作業が異なり、導入の難易度が上がるというトレードオフが存在します。
ネットワークエンジニアの視点:アプライアンス製品の対応と課題
現場の懸念:アプライアンス製品のACME対応
ACMEによる自動化は、Webサーバー(Apache、Nginxなど)やロードバランサー(F5 BIG-IP、A10 Networksなど)では比較的情報が豊富であり、対応が進んでいます。しかし、現場のネットワークエンジニアにとって、真に問題となるのはNW機器やアプライアンス製品の対応です。
ファイアウォールやVPNゲートウェイといったアプライアンス製品は、その性質上、OSのアップデートサイクルが長く、ACMEのような新しいプロトコルへの対応が遅れがちでした。
FortiGateのACME対応状況と技術的制約
主要なアプライアンス製品の中には、ACME対応を積極的に進めているものもあります。例えば、弊社で多く導入実績のあるFortiGateは、FortiOS 7.0以降でACMEクライアント機能がネイティブにサポートされています。
これにより、FortiGateの管理画面アクセスやSSL-VPN用の証明書を、比較的容易に自動更新できるようになりました。
しかし、「FortiGateでACMEが使える」ことが、「全ての証明書が自動化できる」ことを意味しない点に注意が必要です。たとえば、FortiGateをロードバランサーとして利用し、仮想サーバーに証明書を適用する場合など、特定の用途においては、ネイティブ機能だけでは対応しきれず、依然として外部の自動化ツールや設計上の工夫が必要となる場合があります。
ACME非対応機器への現実的な回避策
多くのNW機器メーカーはACME対応を進めていますが、すべての機器が対応するわけではありません。特に、メーカーがファームウェアアップデートを終了したレガシーなアプライアンス製品は、ACME非対応のまま残る可能性が高いと推測されます。
このような場合、ネットワークエンジニアは以下の構成変更を検討する必要があります。
1. リバースプロキシの活用
ACME非対応の機器を直接インターネットに公開せず、前段にACMEクライアントを搭載したリバースプロキシ(Nginxなど)を配置します。プロキシ側で証明書を自動更新し、非対応機器との通信は内部ネットワークの安全な経路で行います。
2. 外部自動化ツールの導入
AnsibleやVaultといった証明書ライフサイクル管理(CLM)ツールを導入し、API経由で証明書を集中管理・配布する仕組みを構築します。
これらの回避策は単なる技術的な対応に留まらず、インフラ全体の設計思想の転換を意味します。
まとめ:2026年以降、インフラ運用に求められる備え
TLS証明書の有効期間短縮は、単なる技術仕様の変更ではなく、企業のインフラ運用における「手動から自動化へ」という大きな転換を強制するものです。
2026年3月15日を皮切りに、証明書の更新頻度は加速度的に増加します。この変化に対応するためには、機器のファームウェアアップデートの動向を注視し、ACME対応を計画的に推進することが不可欠です。
特に、NW機器やアプライアンス製品のACME対応状況は、メーカーやバージョンによって大きく異なります。自社のインフラ環境を棚卸し、どの機器がACMEに対応し、どの機器が構成変更を必要とするのかを早期に判断することが、サービス停止という最悪の事態を避けるための鍵となります。
ヤングライフプロポーサルは、現場のネットワークエンジニアとしての知見を活かし、お客様の証明書管理の自動化、およびインフラ設計の最適化をサポートいたします。まずはお気軽にご相談ください。