AppleがTLSサーバー証明書の有効期間を45日間に短縮することを提案

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日に短縮する内容。
2024/12/12に、最大有効期間を398日から47日にし、また短縮の開始時期も遅らせる案が公開された。
賛否両論あり、多くの書き込みが行われている状況である。

Expand Section 4.2.1 to detail allowed data reuse periods for validation data (both for domains/IPs and for everything else in 3.2)
Overall reduction of non-SAN validation reuse from 825 to 366 days
Overall reduction of SAN validation reuse from 398 days to 10 days
Expand section 6.3.2 to detail schedule of reducing maximum validity periods in coming years
Overall reduction of maximum validity period from 398 days to 45 days
These reductions are proposed to occur starting in September 2025 through September 2027

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

過去、Appleは「Apple Root Certificate Program」を2020年3月に変更し、認証局（CA）に対し2020年9月1日以降に発行する証明書の有効期間を825日から398日にしたことがある。

（参考）

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

Changes in TLS Server Certificate Validity Periods.

pki.world-tls.com

2023.02.01

賛成意見の要約

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

反対意見の要約

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

提案内容（2024/10/10公開）

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 検証データ（ドメイン検証）データ再利用の最大許容期間

提案内容（2024/12/12公開）

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 検証データ（ドメイン検証）データ再利用の最大許容期間

意見

賛成意見

• 提案はパブリック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：有効期間短縮の提案

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)