CA/Browser Forumは2025年4月、TLS証明書の最大有効期間を現行の398日から段階的に短縮し、2029年3月までに47日とする投票結果（Ballot SC-081v3）を正式に承認した。ブラウザベンダー4社（Apple、Google、Microsoft、Mozilla）が全会一致で賛成し、証明書発行者25社も賛成票を投じた。本記事では、この決定がインフラ運用に与える影響と、証明書ライフサイクル管理（CLM）の自動化戦略を実装レベルで解説する。

Ballot SC-081v3 ── 投票の経緯と決定内容

2024年10月9日、AppleはCA/Browser Forumの秋季対面会議でTLS証明書の有効期間短縮を提案した。Sectigoが公式スポンサーとなり、Ballot SC-081v3として正式に起草された。投票は2025年1月28日に開始され、同年4月11日に締め切られた。

結果は圧倒的な賛成多数であった。証明書発行者（CA）は25社が賛成、反対はゼロ、5社（Entrust、IdenTrust、日本レジストリサービス、SECOM Trust Systems、TWCA）が棄権した。ブラウザベンダーはApple、Google、Microsoft、Mozillaの4社全てが賛成し、反対票は一切なかった。

この決定により、TLS証明書の最大有効期間は以下のスケジュールで段階的に短縮される。

施行日最大有効期間DCV再利用期間
現行〜2026年3月14日398日398日
2026年3月15日200日200日
2027年3月15日100日100日
2029年3月15日47日10日

最終段階ではドメイン制御検証（DCV）の再利用期間もわずか10日に短縮されるため、証明書の更新だけでなくドメイン所有権の再検証も頻繁に必要となる。年1回の手動更新で済んでいた運用が、年間8回以上の更新サイクルに変わることを意味する。

手動管理の限界 ── 8倍に増加する更新負荷

DigiCertの2025年調査（Trust Pulse Survey）によると、証明書関連のインシデントにより31%の組織が5万〜25万ドルの損失を報告し、18.5%は25万ドル以上の損失を被っている。さらに45%の企業が過去1年間に証明書の期限切れによるサービスダウンタイムを経験しており、そのうち50%以上が5〜24時間の停止に至った。

現行の398日サイクルですらこの状況である。47日サイクルに移行すれば、手動管理の運用コストは単純計算で約8倍に跳ね上がる。1件の証明書更新にかかる工数は平均3〜6時間とされており、1,000〜10,000枚の証明書を管理する組織（DigiCert調査で約60%）にとって、手動運用の継続は現実的ではない。

注目すべきは、投票で棄権した5社のうち日本レジストリサービスとSECOM Trust Systemsが含まれている点である。日本国内の認証局が棄権した背景には、国内企業の自動化対応の遅れに対する懸念があると考えられる。手動管理に依存する日本企業は、2026年3月の最初の短縮期限までに自動化基盤を整備する必要がある。

ACMEプロトコルによる自動化の実装

ACME（Automatic Certificate Management Environment）は、IETF RFC 8555で標準化された証明書管理の自動化プロトコルである。Internet Security Research Group（ISRG）がLet's Encryptのために設計し、HTTPSを介したJSONメッセージでCAとサーバー間の対話を自動化する。

ACMEの実装手順は以下のとおりである。

  1. ACMEクライアントの選定: Certbot（EFF製、Python）、acme.sh（シェルスクリプト）、Lego（Go言語）が代表的なクライアントである。Kubernetesを利用する環境ではcert-managerが事実上の標準となっている。
  2. チャレンジ方式の設定: ドメイン所有権の検証にはHTTP-01（ポート80でのファイル配置）、DNS-01（DNSレコード追加）、TLS-ALPN-01（TLS拡張）の3方式がある。ワイルドカード証明書にはDNS-01が必須である。
  3. 自動更新の構成: cronジョブまたはsystemdタイマーで、証明書の有効期限の30日前（47日証明書の場合は15日前が推奨）に更新を実行する。更新後のWebサーバーリロードも自動化する。
  4. 監視の設定: Certificate Transparencyログの監視と、更新失敗時のアラート通知を構成する。ACME更新の成功率と残り有効日数をPrometheusなどの監視システムに統合することが望ましい。

Netcraftの2025年データによると、DV（Domain Validated）証明書の94.3%はLet's Encryptなどの自動化プロバイダーから発行されており、単純なWebサーバーにおける自動化はすでに業界標準である。課題は、ロードバランサー、CDN、IoTデバイス、内部ネットワーク機器など、ACMEを直接サポートしない環境での自動化にある。

CLMプラットフォームの選定基準

エンタープライズ環境では、単一のACMEクライアントでは管理しきれない。Certificate Lifecycle Management（CLM）プラットフォームは、組織内の全証明書を一元管理し、マルチCA対応、ポリシー適用、コンプライアンス監査を統合的に提供する。

主要なCLMプラットフォームは以下のとおりである。

  • Venafi TLS Protect（CyberArk傘下）: マシンアイデンティティ管理の先駆者。ハイブリッドクラウド・マルチクラウド環境に強い
  • Keyfactor Command: PKI-as-a-Serviceを含む統合プラットフォーム。証明書の自動発見・棚卸し機能が充実
  • Sectigo Certificate Manager: パブリック・プライベート証明書の統合管理。Ballot SC-081v3のスポンサーとして47日対応を積極推進
  • DigiCert Trust Lifecycle Manager: エンタープライズ向けのフルスタックCLM。CT（Certificate Transparency）ログとの統合に優れる
  • AppViewX CERT+: ネットワーク機器とSSH鍵の管理にも対応する汎用プラットフォーム

選定にあたっての重要な評価基準は、(1) 既存インフラとの統合性（F5、AWS、Azure、GCPとのコネクタ）、(2) マルチCA対応（ベンダーロックイン回避）、(3) シャドーIT検出（未管理証明書の自動発見）、(4) ポスト量子暗号（PQC）対応のロードマップ、の4点である。

ポスト量子暗号アジリティとの接点

47日証明書への移行は、単なる運用効率の問題にとどまらない。2029年の47日完全施行と、NISTが推進するポスト量子暗号（PQC）への移行は時期が重なる。この一致は偶然ではなく、暗号アジリティ（Crypto Agility）を業界全体に浸透させる戦略的な布石であるとされている。

暗号アジリティとは、暗号アルゴリズムの変更を危機対応ではなくルーチンとして実行できる能力を指す。47日ごとの証明書更新を自動化する組織は、将来的にRSA-2048やECCからML-KEM（旧CRYSTALS-Kyber）やML-DSA（旧CRYSTALS-Dilithium）への切り替えも、証明書更新サイクルの中で段階的に実施できる。

GlobalSignは「47日証明書によって頻繁な自動更新が常態化すれば、PQCアルゴリズムへの移行はスムーズなルーチン作業となる」と述べている。逆に言えば、47日更新を手動で回している組織は、PQC移行時にも危機的な状況に陥るリスクが高い。証明書自動化は、量子コンピューティング時代のセキュリティ基盤でもある。

実務ロードマップ ── 2026年3月に間に合わせるために

最初の短縮（200日）は2026年3月15日に施行される。残り時間は限られている。以下に優先度順の実務ロードマップを示す。

  1. 証明書棚卸し（即時）: 組織内の全TLS証明書を洗い出す。CT（Certificate Transparency）ログ、ネットワークスキャン、CLMツールの自動発見機能を活用し、シャドー証明書を含めて把握する。
  2. ACME対応の確認（2026年Q1）: 各証明書の発行元CAがACMEをサポートしているか確認する。Let's Encrypt、DigiCert、Sectigo、GlobalSignなど主要CAはACME対応済みである。非対応のCAを利用している場合は移行を検討する。
  3. 自動化パイプラインの構築（2026年Q1〜Q2）: Webサーバー（Nginx、Apache）はCertbotまたはacme.sh、KubernetesはCert-manager、クラウドはマネージド証明書（AWS ACM、Azure Key Vault、GCP Certificate Manager）を活用する。
  4. CLMプラットフォームの導入検討（2026年Q2）: 証明書が100枚を超える組織は、エンタープライズCLMの導入を検討すべきである。POC（概念実証）を実施し、既存環境との統合性を検証する。
  5. 更新失敗時の対応手順策定（2026年Q2）: ACME更新が失敗した場合のフォールバック手順、エスカレーションフロー、および緊急時の手動更新プロセスを文書化する。47日サイクルでは1回の更新失敗がサービス停止に直結するため、冗長性の確保が不可欠である。

FAQ

なぜCA/Browser ForumはTLS証明書の有効期間を47日に短縮するのか？

証明書に記載されたドメイン所有権や組織情報は時間の経過とともに正確性が低下する。有効期間を短縮することで、失効した情報や漏洩した秘密鍵が悪用されるリスクウィンドウを大幅に縮小できる。Appleの提案理由書には「証明書の情報は時間とともに信頼性が低下する」と明記されている。

Let's Encryptを使っていれば47日対応は不要か？

Let's Encryptの証明書は現行で90日有効であり、ACMEによる自動更新が前提の設計である。そのためLet's Encrypt利用環境では大きな影響はない。ただし、DCV再利用期間が10日に短縮されるため、DNS-01チャレンジの自動化が完全に動作していることを確認する必要がある。

EV証明書やOV証明書も47日になるのか？

Ballot SC-081v3はDV、OV、EVの全タイプのTLS証明書に適用される。EV証明書は組織の実在性検証を含むため更新コストが高く、特に自動化の恩恵が大きい。一部のCAはEV証明書のACME対応を進めている。

47日証明書の時代に証明書ピンニングは使えるのか？

HTTP Public Key Pinning（HPKP）はすでにChromeで非推奨となっており、47日サイクルでは実質的に運用不可能である。代替としてCertificate Transparency（CT）ログの監視とCAA（Certification Authority Authorization）レコードの設定を推奨する。

参考文献