TLSサーバー証明書の有効期間が2029年までに47日間に

The English version is here（英語版はこちら）

TLSサーバー証明書の有効期間が最短47日に

Ballot SC-081v3では、TLS Baseline Requirements（TLS BR）に対する抜本的な見直しが提案され2025年4月11日、投票通過した。

証明書の有効期間短縮スケジュール

• 現行の最大有効期間398日を最終的に47日まで短縮
• 有効期間短縮は2026年3月に開始、2029年3月までに完了

（参考）

TLSサーバー証明書の有効期間の変遷

Changes in TLS Server Certificate Validity Periods.

pki.world-tls.com

2023.02.01

最大有効期間は47日へ

サブスクライバー証明書（TLSサーバ証明書など）の最大有効期間は次のとおり。

検証データの再利用期間も大幅短縮

• サブジェクト名（SAN）に関する検証データ再利用期間：最終的に10日
• SAN以外の情報（例えば組織情報など）：最終的に398日

ドメインやIPアドレスの検証データ再利用期間は、以下のとおり段階的に短縮される。

組織名や住所など、証明書に記載されるサブジェクト情報の検証データは、以下のように再利用期間が変更される。

なぜ今、有効期間の短縮なのか

Web PKIはインターネットの安全を支える重要なインフラ。証明書は「発行時点の正しさ」を保証するが、時間の経過とともに情報が現実と乖離していく。
短期間の証明書やデータ再検証によって、次のようなリスクの軽減が期待される：

• ドメイン移管・失効・不正アクセスなどによるなりすまし被害の抑止
• 不適切な検証等による誤発行の影響範囲を縮小
• 自動更新インフラの整備促進による運用の安定化
• 失効情報（CRL/OCSP）の性能・信頼性不足を補完
• 暗号アルゴリズム変更時のスムーズな移行が可能に

失効チェックへの過度な依存はリスク

証明書の失効情報はリアルタイムで取得しにくく、信頼性やプライバシーにも課題が多い。証明書の短命化によって、失効チェックに頼らずとも自然失効が期待できる構造に近づける。

Google ChromeとMicrosoft Edgeは、ウェブ閲覧の都度、CRL（Certificate Revocation List）やOCSP（Online Certificate Status Protocol）を用いた失効検証を行っていない。これらのブラウザは、ユーザーがウェブサイトにアクセスする際に、証明書の失効状態を確認するために、毎回認証局に問い合わせるのではなく、CRLSetsという仕組みを利用している。この方法では、失効した証明書の情報が定期的に更新されるリストを使用するが、すべての失効証明書が含まれているわけではない問題がある。

今後も続く短縮化

有効期間短縮の動きは、47日間で完了せず、Short-lived証明書（7日以内の有効期間）に向かっていくのではないかと考えられる。

Short-lived証明書は、非常に短い有効期間を持つ証明書であり、証明書が不正に取得されるリスクを最小限に抑えることができ、証明書の更新作業が自動化されることで管理の効率化も図れる。CRL Distribution Points拡張やOCSP（オンライン証明書状態プロトコル）拡張が不要となり、失効検証が一切不要となっている。もし、Baseline Requirementsに該当する失効要件に該当した事象が発生したとしても、失効除外の対象となっている。

想定される問題点としては、以下が挙げられる。

大量の証明書発行処理によるインフラ負荷

短期証明書は有効期間が7日（2026年以降）と非常に短いため、全世界のサーバーが週1回程度の頻度で証明書を再取得する必要がある。これにより、CAのインフラ、CTログ、APIバックエンドなど、あらゆる関連システムへの負荷が激増する。

自動化失敗によるサービス停止リスク

自動化を前提とするとはいえ、スクリプトやバッチ処理のエラー、DNS不整合、APIの一時障害などで証明書の更新に失敗するリスクが高まる。これにより、証明書期限切れによるサービス停止が頻発する可能性がある。

クライアント側キャッシュの非効率化

短期間で証明書が頻繁に変わると、ブラウザや他のクライアントが証明書チェーンを毎回ダウンロードし直す必要が出てくる。これによりネットワーク帯域の使用量や端末側の処理負荷が増える。

IoTや組込みデバイスでの対応困難

自動更新機構を持たない、または更新のためのネットワーク接続が制限されているデバイス（例：スマートメーター、医療機器、センサーなど）では適用が非常に困難となる。

Ballot SC-081v3 投票結果一覧

※ MOISは、投票期間外の投票なのでカウントされない。

集計結果

• Yes: 28
• Abstain: 5 (MOISを除く)
• No: 0

背景にあったChrome Root Program Policy v1.6の改訂

2025年2月15日に更新されたChrome Root Program Policy v1.6における重要な改訂点が、証明書の有効期間に大きな影響を与える可能性がある。
2025年9月15日以降に申請されたルート証明書は、TLSサーバー証明書の有効期間を最大90日に制限することが求められる。これにより、今後、証明書発行においては、90日以内に証明書を更新するための仕組みが強制されることとなる。

しかし、この変更はすべての証明書に即時適用されるわけではない。2025年9月15日以降に申請された証明書が対象となるため、それ以前に発行された証明書については当面影響を受けない。また、ルート証明書については、5年ごとに入れ替えが行われるため、最終的には2030年9月頃までにはすべての証明書が90日に対応する形で入れ替えが完了する予定であり、Ballotの成立を待つことなく移行が進む見込みであった。

AppleとGoogleの関係性

Chromeを提供しているGoogleは、AppleやMozillaなどのブラウザ開発企業に対して、Google検索をデフォルト検索エンジンとして設定するために多額の支払いを行っている。​これらの支払いは「search default placement fee（検索デフォルト設定料）」と呼ばれ、Googleの検索市場における支配力を維持するための重要な戦略の一部とされている。​

2022年、GoogleはAppleに対して約200億ドル（約2.7兆円）を支払い、iPhone、iPad、MacのSafariブラウザにおけるデフォルト検索エンジンの地位を確保した。 この金額は、Appleの年間営業利益の約16.75%に相当する。 ​

なお、GoogleのChrome Root Program Policy v1.6変更時期と今回のBallotのディスカッションは時期が重なっている。

Appleによる有効期間短縮の提案経緯

2024/10/10に、AppleのClint Wison氏が以下のCABFのBaseline Requirements改訂案（Ballot SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods）を提案した。
TLSサーバー証明書の最大有効期間を398日から45日に短縮する内容。（SC-081）
2024/12/12に、最大有効期間を398日から47日にし、また有効期間短縮の開始時期も遅らせる案が提示された。（SC-081v2）
2025/03/06に、短縮の開始時期をさらに遅らせる案が提示された。（SC-081v3）
2025/04/04～04/11が、投票期間となり、YES多数のため、2025/04/11にBaseline Requirementsに採用される見通しとなった。
https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/bvWh5RN6tYI/m/6yPQAxRcCAAJ

賛成意見の要約

パブリックCAエコシステムの健全化に向けた正しい方向であり、自動更新をサポートできないシステムは内部CAやリバースプロキシ、WAFの背後に配置すべき。主要ブラウザも証明書有効期間のクライアント側検証を強化する見込み。内部CAを運用することで証明書の有効期間を完全に管理できるが、セキュリティと可用性の確保が必要。Appleはユーザーの安全な通信を保護する責任があり、ACMEをサポートするベンダーも存在。短期間の証明書は暗号化の柔軟性を向上させ、管理者に定期的な更新を促す。自動化ツールの普及により、ITチームの負担軽減と大規模な失効イベント時の迅速なローテーションが可能に。提案の意図はエラーの減少、停止の減少、「古い証明書」の減少、攻撃の持続性の減少にある。

反対意見の要約

提案内容はIT業界での経験不足を示唆し、多くのソフトウェアパッケージやハードウェアがACMEをサポートしていない現状では非現実的。特にWindows環境やレガシーアプリケーションでのACMEサポートの欠如が問題。パブリックCA証明書の価格上昇とビジネスPKIコストの増加、Let’s Encryptの失敗リスク、提案に対する1年では短すぎる猶予期間、IoTデバイス対応の懸念などが挙げられる。電子署名用証明書との有効期間の矛盾や技術的負債、予算や人員の不足も問題視されている。提案の強制的な自動化はすべてのユースケースに適しておらず、セキュリティリスクと管理負担の増加が懸念される。

通過した提案内容（2025/03/06公開）SC-081v3　※2025/04/11に投票通過

https://github.com/cabforum/servercert/compare/b7fd69b36171d81930e7758482984ce957a1ce7a…5f7247ef354cf202c8c6e617bfc4a89e080a085d

証明書の最大有効期間

SAN 以外の検証（組織の実在性等）データ再利用の最大許容期間

SAN 検証データ（ドメイン検証）データ再利用の最大許容期間

過去の提案内容（2024/12/12公開）SC-081v2

SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods by clintwilson · Pull Request #553 · cabforum/servercert

Expand Section 4.2.1 to detail allowed data reuse periods for validation data (both for domains/IPs and for everything e...

github.com

証明書の最大有効期間

SAN 以外の検証（組織の実在性等）データ再利用の最大許容期間

SAN 検証データ（ドメイン検証）データ再利用の最大許容期間

過去の提案内容（2024/10/10公開）SC-081v1

Baseline Requirements 4.2.1を拡充し、バリデーションデータの再利用期間を詳細に規定する（ドメイン/IPおよび3.2におけるその他すべてに適用）。

SAN以外の検証（組織の実在性等）の再利用期間を825日から366日に短縮。
SAN検証（ドメイン検証）の再利用期間を398日から10日に短縮。
6.3.2を拡充し、今後数年間の最大有効期間短縮のスケジュールを詳細に規定する。
TLSサーバー証明書の最大有効期間を398日から45日に短縮。
これらの短縮は、2025年9月から2027年9月にかけて実施される。

6.3.2は、サブスクライバー証明書の有効期間を制限する。
CAは、証明書情報を確認するために3.2に記載されている文書およびデータを使用するか、または以前のバリデーションを再利用することができる。
ただし、CAは3.2に指定されたソースからデータや文書を取得するか、次の表に記載されている証明書発行前の最大日数以内にバリデーションを完了している必要がある。

証明書の最大有効期間

SAN 以外の検証（組織の実在性等）データ再利用の最大許容期間

SAN 検証データ（ドメイン検証）データ再利用の最大許容期間

ディスカッション中の意見

賛成意見

• 提案はパブリックCAエコシステムの健全化に向けた正しい方向。
• 自動更新方法をサポートできないシステムは、内部CAかリバースプロキシ、WAFの背後に置くべき。
• CAから発行された証明書を内部システムに使用する場合、内部CAを使用するのが望ましい。
• 自社内部CAを運用すれば証明書の有効期間を完全に管理できるが、その代わりにCAのセキュリティと可用性を確保する負担がある。
• 提案が採用されれば、主要ブラウザも証明書有効期間のクライアント側検証を強化。
• 内部CAを運用したくない場合、PKIaaSやマネージドPKIサービスを利用できる。
• AppleはiPhone、iPad、Macのユーザーの安全な通信を保護する責任を負っている。
• 一部のベンダーはACMEをサポートしている（例：FortiGate 7.0+）。
• リモートユーザーVPNにも内部CAを使用可能だが、公開CAを使用する場合もACMEの統合が可能。
• ACMEのサポートは多くの場所で提供されており、自動化することでITチームの負担が軽減される。
• システムがすべてACME対応になるのを待っていたら、何も進まない。
  自動化ツールとサービスが広く利用可能であり、証明書の有効期間が短縮されるのは初めてではない。
• 2020年にAppleがSafariの証明書有効期間を一方的に短縮したが、今回は1年の通知期間が与えられている。
• 短期間の証明書はエコシステムの暗号化の柔軟性を向上させ、管理者が鍵を定期的に更新することを奨励する。
• 提案は良いアイデアであり、変更を1年ごとに均等にスペースを置くことが望ましい。
• 提案の意図は、自動化を促進してエラー（特に鍵の侵害）を減らし、大規模な失効イベント時に証明書の迅速なローテーションが必要な際の停止を減らし、有効期限を短くすることで「古い証明書」を減らし、BGPハイジャックなどの攻撃の持続性を減らすこと。
• WiFiシステムと統合されている場合、アウトバウンド接続があり、証明書を取得できる。
• 完全にオフラインの場合でも、コンテンツの更新時に証明書をインストールできる。
• Appleのような大企業は大規模な技術変更を短期間で行うための予算を持っている。
• 短期間の証明書はエコシステムの暗号化の柔軟性を向上させ、管理者が鍵を定期的に更新することを奨励する。
• 提案は良いアイデアであり、変更を1年ごとに均等にスペースを置くことが望ましい。

反対意見

• 提案内容は、IT業界での経験が不足していることを示唆。
• ソフトウェアパッケージやハードウェアプラットフォームの多くがACMEや類似の自動デバイス証明書ロールオーバーをサポートしていないため、現実的ではない。
• IIS、Tier 1ファイアウォールベンダー、IoTデバイス、小規模SASベンダーの多くが対応していない。
• Linuxでは、CertbotのようなACMEクライアントが広く使用されており、成熟したエコシステムが存在するが、Windows向けのツールやサポートはまだそこまで充実していない。
• レガシーアプリケーションとサポート中のアプリケーションの両方でACMEの欠如が問題。
• Appleはサーバー領域での実績がないため、この提案の信憑性に疑問がある。
• パブリックCAの証明書価格が上昇し、ビジネスPKIコストが増加。
• Let’s Encryptが失敗すれば、パブリックインターネットに大規模な障害が発生する可能性。
• 提案に対する対応策や機能が1年間で提供されない場合、ベンダーからの移行を検討するべき。
• 提案された2025年9月から2027年9月の期間ではなく、2027年9月から2029年9月までの2年間の猶予が必要。
• 既存の有効期間変更がIT専門家に負担をかけているため、対応が遅れる可能性がある。
• 証明書の交換はベンダーとの間で多く行われ、ITスタッフの負担が増加。
• IoTデバイスの対応が最大の懸念。
• 電子署名用の証明書が3～5年の有効期間を持つのに対し、TSL/SSL証明書の有効期間が短く設定されている理由の説明を求める。
• 証明書の有効期限を短縮するのではなく、信頼できるCAの選定に重点を置くべき。
• 技術的な負債が生じる可能性があり、対応には時間がかかる。
• 12か月の猶予期間でシステムを更新するための予算や人員が不足している可能性。
• 多くのベンダーが対応準備ができていない。
• 個人所有のモバイルデバイスがローカルWi-Fiネットワークを通じてシステムとHTTPSで通信する場合、インターネット接続が限定的または存在しないシステムが多い。
• 現在は商用証明書を購入し、手動でインストールして12か月ごとに更新しているが、提案により45日ごとに更新が必要になる。
• 現実的な代替手段はTLSを使用しないか、自己署名証明書を使用してユーザーに警告を無視させることだが、どちらも望ましくない。
• 証明書の有効期限を短くするよりも、失効に依存する方が良い。
• 提案は非常に論争的であり、ACMEなどの自動化プログラムの使用を強制するもの。
• TLSサーバー証明書には鍵の保護が不要であるため、法的効力を持つためには認定署名作成デバイスが必要。
• 短期証明書の概念を理解しているが、TSL/SSL証明書には現時点で現実的ではない。
• TSL/SSL発行者はヨーロッパの(Q)TSPのように規制されていないため、再発行された証明書が同じ鍵を使用しないことをどのように確保するかが問題。
• ヨーロッパではQWACが導入されているが、既に高度に規制されているTSPに同じ要件を課すべきか。
• ACMEは多くのチャレンジタイプをサポートしているが、すべての状況やリスクプロファイルに適しているわけではない。
• HTTP-01やTLS-ALPN-01は証明書が必要なシステムへの直接アクセスを必要とし、攻撃面が増え、398日の有効期限を持つ証明書よりリスクが高くなる可能性がある。
• 多くのDNSゾーンベンダーは細かいアクセス制御を提供していないため、DNS-01チャレンジでは広範な書き込み権限が必要になり、これもリスクが高くなる可能性がある。
• 中間ソリューション（他のシステムに代わってACMEリクエストを行う境界システム）は未成熟であり、ACME自体よりも互換性が低い。
• 提案がACMEの使用を強制する間接的な手段である場合、これらのユースケースに対するセキュリティリスクを増大させ、管理負担も増える。
• 提案の意図と目的に関する詳細情報を求める。
• 投票が必要ならば反対票を投じる。問題はリコールチェックをバイパスするアプリケーションにあり、それを修正すべき。
• 自動化がすべてのユースケースに適しているわけではなく、この提案がエラーや障害を増加させる可能性がある。
• 構築されたシステムや「凍結」されたデバイスは、証明書や設定の更新管理が非常に難しい。
• 年間証明書を購入する余裕がほとんどない企業は、無料のACME証明書に切り替えるが、これらは簡単に「ハッキング」される可能性がある。
• 投票はAppleの決定を変えない。以前の投票では証明書有効期間の短縮が否決されたが、AppleはSafariで一方的に変更を実施した。
• CABフォーラムの投票結果がメンバーによって従われない場合、投票の意義は何か。CABフォーラムの役割はAppleのようなブラウザ運営者より重要でないのか。
• Web PKIは過去10年間で証明書の有効期限を短縮する方向に進んできたが、これが正しい方向だったのかという疑問。
• 約1.78%の鍵が侵害されたため、残りの98.22%が自動化を強制されるのかという懸念。

過去のGoogleによる有効期間短縮の提案（2024年10月）

Googleは、「Moving Forward, Together (2024-10-09)」で将来的に有効期間の短縮化に向けてPolicy検討していた。
2014年4月に「Heartbleed」の脆弱性で50万以上の証明書入れ替えが発生した。本来、24時間以内の失効が必要であったが、1か月以内に入れ替えが完了したのは14%であった事実を引用している。

提案されていた証明書の最大有効期間。

• TLSサーバー証明書: 90日
• 下位CA証明書: 3年

Root CA証明書は「Chrome Root Program Policy, Version 1.5」で現状15年になっていた。

TLS Server Authentication Certificates

In April 2014, a security vulnerability (“Heartbleed”) was discovered in a popular cryptographic software library used to secure the majority of servers on the Internet that broke the security properties provided by TLS. It was estimated that over 500,000 active publicly accessible server authentication certificates needed to be revoked and replaced as a result of Heartbleed.

In response to instances where a certificate’s private key is either 1) compromised or 2) demonstrated weak, CA/Browser Forum TLS Baseline Requirements dictate revocation must take place within 24 hours. Despite a demonstrated vulnerability, remediation efforts from website operators in response to Heartbleed were slow. Only 14% of affected websites completed the necessary remediation steps within a month of disclosure. About 33% of affected devices remained vulnerable nearly three years after disclosure.

Despite Heartbleed taking place over 10 years ago, the reality remains that at any point in time, a TLS certificate is no more than 24-hours away from required revocation, and based on recent publicly disclosed Web PKI incident reports, it appears that the ecosystem is not yet prepared to respond as necessary.

Peer reviewed research also demonstrates that reduced TLS certificate lifetime improves security. For example, in scenarios where a third party maintains control over a TLS certificate and private key, a shorter certificate lifetime implies a shorter window in which the third party can still use the key when they might no longer be authorized to possess it.

Beyond these unambiguous security needs, reducing TLS certificate lifetime encourages automation and the adoption of practices that will drive the ecosystem away from baroque, time-consuming, and error-prone issuance processes. These changes will allow for faster adoption of emerging security capabilities and best practices. Decreasing certificate lifetime will also reduce ecosystem reliance on “broken” revocation checking solutions that cannot fail-closed and, in turn, offer incomplete protection. Currently, our proposed maximum TLS server authentication subscriber certificate validity is ninety (90) days.

Subordinate CA Certificates

Much like how introducing a term-limit for root CAs allows the ecosystem to take advantage of continuous improvement efforts made by the Web PKI community, the same is true for subordinate CAs. Promoting agility in the ecosystem with shorter subordinate CA lifetimes will encourage more robust operational practices, more closely align relied-upon certificate profiles with modern best practices, reduce ecosystem reliance on specific subordinate CA certificates that might represent single points of failure, and discourage potentially harmful practices like key-pinning. Currently, our proposed maximum subordinate CA certificate validity is three (3) years.

Moving Forward, Together (2024-10-09)