TLS SSL 03-31-2026

TLS 証明書ルールの変更：2026年〜2029年のタイムライン

パブリック TLS 証明書を規定するルールには、すでに大きな変更が進行しており、その動きは 2029 年まで続く見込みです。いくつかの更新は 2026 年 2 月に施行されており、3 月以降も業界全体で追加の要件が導入されます。

これらの変更は、Google Chrome が主導する CA/Browser Forum とブラウザのルートプログラムに由来します。証明書の有効期間、検証再利用期間、DNSSEC の適用、マルチパースペクティブ発行検証（MPIC）、およびクライアント認証のユースケースに影響を与えます。

これらの更新は段階的に展開されるため、計画が極めて重要です。以下に、すでに施行されている内容、今後予定されている内容、そしてパブリック TLS 証明書を利用している組織にとっての意味を時系列で示します。

すでに施行されている変更（2026 年 2 月〜3 月上旬）

いくつかの重要な変更は、すでに施行されています。

2026 年 2 月 24 日：有効期間と再利用期間の短縮

デジサートは、有効期間が 199 日を超えるパブリック TLS 証明書の申請を受け付けなくなりました。2026 年 2 月 24 日以降に発行される証明書は、199 日を超えることはできません。

検証再利用期間も以下の通り短縮されました。

ドメイン制御検証（DCV）： 199 日
組織認証（OV）： 397 日

今後、更新計画はこの短縮されたライフサイクルに合わせる必要があります。

2026 年 2 月 24 日：DNSSEC 検証の適用（有効時）

デジサートは DNSSEC の検証を実施するようになりました。これは、設定されている場合に、ドメイン制御の確認および DNS Certification Authority Authorization（CAA）チェック時に適用されます。

DNSSEC 自体は必須ではありません。ただし、DNSSEC が有効になっている場合は、設定不備のある DNSSEC によって証明書の発行が妨げられる可能性があります。

2026 年 3 月 3 日：MPIC 適用の強化

デジサートは MPIC プロセスを更新し、少なくとも 2 つの Regional Internet Registry（RIR）地域にまたがる少なくとも 3 つのリモートネットワーク視点を使用するようになりました。

グローバルに一貫しない DNS または HTTP 応答は、今後検証時に顕在化する可能性があり、グローバルで安定した構成の重要性が高まります。DCV の実施方法によっては、MPIC の下で証明書発行の問題を回避するためにネットワーク構成の調整が必要になる場合があります。実装の詳細については、こちらのナレッジベース記事をご確認ください。

2026 年 3 月 15 日：業界全体での適用

2026 年 3 月 15 日に、CA/Browser Forum の要件がすべてのパブリック TLS 証明書に適用されます。

検証方法の変更：

CA は IP アドレス方式を使用してドメインの管理権限を検証することができなくなります。
証明書にはドメイン名を含めることができません。対象は、IP リバースゾーンのサフィックスで終わるドメイン名です。
Precertificate Signing CA は、precertificate の発行に使用できなくなります。

DNSSEC の適用：

必要な DNS クエリについては、IANA の DNSSEC ルートトラストアンカーまで DNSSEC 検証を実施しなければなりません。
DNSSEC 検証エラー（例：SERVFAIL）を、発行の許可として扱ってはなりません。
ローカルポリシーによって、ドメインの認可または管理権限の確認に対する DNSSEC 検証を無効にすることはできません。

MPIC 要件：

CA は MPIC を実装しなければなりません。少なくとも 2 つの RIR 地域にまたがる 3 つ以上のリモートネットワーク視点を使用する必要があります。

証明書の有効期間および再利用制限：

TLS 証明書の最大有効期間： 200 日
ドメインおよび IP 検証の再利用： 200 日
主体 ID 情報の再利用： 398 日

これらの制限はエコシステム全体に適用されます。上記の通り、デジサートは 3 月 15 日に先立ち、すべてのシステムが完全に整合し安定した状態になるよう、また CA/B Forum の新しい 200 日制限を超える証明書を発行するリスクを防ぐため、これらの変更を前倒しで 2 月 24 日に適用しました。また、継続的な準拠を確保するために、有効期間の上限を CA/Browser Forum の最大値より 1 日短く設定しています。

2026 年：WebPKI TLS におけるクライアント認証の段階的廃止

パブリック TLS 証明書は、サーバー認証専用の用途へ移行しています。クライアント認証（mTLS）は、主に Chrome のルートプログラムを通じて、WebPKI から段階的に廃止されています。

API 認証やマシン間通信のためにパブリック TLS 証明書を使用している組織は、これらのユースケースを慎重に見直す必要があります。

2026 年 5 月 1 日：デジサートが ClientAuth EKU の発行を停止

デジサートは、ClientAuth EKU を含むパブリック TLS 証明書を発行しなくなります。新しい証明書には、サーバー認証 EKU のみが含まれます。 [デジサート独自ルール]

2026 年 5 月 15 日：G2/G3 階層下の ICA 失効

デジサートは、中間 CA（ICA）証明書を失効させます。対象は DigiCert Global Root G2 および DigiCert Global Root G3 のルート階層に連なる ICA 証明書と、それに紐づくすべてのエンドエンティティ証明書です。Chrome Root Program は、サーバー認証以外の目的をサポートするこれらのルートおよび関連ルートを非信頼化する予定です。 [Chrome による 6 月 15 日の非信頼化の前倒し実装]

2026 年 6 月 15 日：Chrome が ClientAuth EKU を含む中間 CA を非信頼化

Chrome は、クライアント認証 EKU を含む中間 TLS 認証局を信頼しなくなります。 [Chrome Root Program ルール]
認証局は、少なくとも 4 つのリモートネットワーク視点を用いて MPIC を実装しなければなりません。検証ネットワークは少なくとも 2 つの RIR 地域に属している必要があります。 [CA/B Forum ルール]

2026 年 8 月 28 日：ClientAuth 購入分は 2027 年に失敗

この日以降に ClientAuth EKU 付きで購入された証明書は、有効期限が残っていても 2027 年 3 月 15 日以降はクライアント認証に使用できなくなります。

2026 年 9 月 11 日：最初の 199 日証明書が期限切れ

2026 年 2 月 24 日の 199 日最大有効期間ルールの下で発行された証明書が、最初に期限切れを迎え始めます。

2026 年 12 月 15 日：MPIC がさらに拡大

認証局は、少なくとも 2 つの RIR 地域にまたがる 5 つ以上のリモートネットワーク視点を用いて MPIC を実装しなければなりません。 [CA/B Forum ルール] [Chrome Root Program ルール]

2027 年 3 月 15 日：100 日証明書と DCV 廃止

2027 年 3 月には、さらに大きな縮小が行われます。

廃止されるドメインおよび IP 検証方法：

以下を含む、いくつかの検証方法が廃止されます。
電話ベースのドメイン検証方法
IP アドレス連絡先へのメール、FAX、SMS、または郵送
IP 検証のための逆引きアドレス検索
IP アドレス連絡先への電話連絡

従来型または手動の検証ワークフローに依存している組織は、この期限までに移行する必要があります。

有効期間短縮の第 2 段階：

TLS 証明書の最大有効期間：100 日
ドメインおよび IP 検証の再利用：100 日
デジサートは最大有効期間を 99 日に設定します。この変更がいつ適用されるかはまだ発表していません。継続的な準拠を確保するために、CA/Browser Forum の最大値より 1 日短く設定します。

Chrome の変更：ClientAuth の非信頼化

Chrome は、クライアント認証 EKU を含む TLS エンドエンティティ証明書を信頼しなくなります。 [Chrome Root Program ルール]

2027 年 6 月上旬：最初の 100 日証明書が期限切れ

100 日の最大有効期間の下で発行された最初の証明書が期限切れを迎え始めます。更新サイクルは、四半期ごとの運用に近いものになります。

2028 年 3 月 15 日：メールベースの DCV 方法の廃止

CA/Browser Forum は、以下のメールベースの検証方法を禁止します。

この変更より十分前に、自動化された DNS ベースまたは HTTP ベースの検証方法を完全に運用可能な状態にしておく必要があります。

2029 年 3 月 15 日：47 日証明書

最後に予定されている短縮により、証明書の有効期間は大幅に短くなります。

TLS 証明書の最大有効期間： 47 日
ドメインおよび IP 検証の再利用： 10 日
デジサートは最大有効期間を 46 日に設定します。この変更がいつ適用されるかはまだ発表していません。継続的な準拠を確保するために、CA/Browser Forum の最大値より 1 日短く設定します。

この段階では、証明書管理は継続的な運用プロセスになります。手動ワークフローではこの頻度に対応できません。

これらの変更が組織に意味すること

有効期間の短縮、より厳格な検証ルール、MPIC 要件の拡大、ルートプログラムの変更が組み合わさることで、組織のトラスト管理のあり方は大きく変わります。その影響は証明書の発行にとどまらず、互換性計画、更新ワークフロー、DNS 構成、自動化戦略にも及びます。

ほとんどの組織が影響を受けるのは、主に以下の領域です。

トラストと互換性のリスク

ブラウザのルートプログラムは、どのルート証明書や中間証明書を信頼対象として維持するかを含め、トラストポリシーを定期的に更新します。ルートが削除されたり用途が制限されたりすると、トラストチェーンが破綻し、ブラウザで重大なエラーが発生します。警告バナーではなく、「証明書は信頼されていません」というエラーによってアクセス自体が完全にブロックされることがあります。

組織は、サポート対象のルート証明書や中間証明書への移行が必要になる場合があり、証明書チェーンの選択にもこれまで以上に注意を払う必要があります。互換性計画は、実際のクライアント構成を反映する必要があります。古いデバイス、組み込みシステム、長期利用されるエンタープライズソフトウェアは、最新の Chrome と同じようには動作しないため、現実の利用環境に即した検証が予期しない障害の回避に不可欠です。

ルート証明書や中間証明書の移行は、机上の話ではありません。これに備えるには、インベントリの可視化、調整された展開、そして本番適用前の検証が必要です。

発行と更新の信頼性

より厳格なマルチパースペクティブ発行検証（MPIC）や短縮された検証再利用期間を含む新しい CA/B Forum 要件により、証明書検証の基準はさらに厳しくなります。

CDN、Anycast ルーティング、またはスプリット DNS により地域ごとに DNS や HTTP の応答が異なると、検証チェックが失敗する可能性があります。認証局（CA）が複数のネットワーク視点から検証を行う場合、一貫しない応答によって発行が遅延したり、更新がブロックされたりすることがあります。

MPIC は運用上は CA 側の責任ですが、その影響は利用組織にも及びます。組織は、グローバルで一貫した DNS 応答、安定した到達性、そして障害を防ぐための十分な更新バッファ時間を確保する必要があります。

短縮されたライフサイクルによる運用負荷

TLS 証明書の有効期間は、年 1 回の更新から 100 日未満のサイクルへと短縮され、最終的には 47 日になります。この圧縮により、証明書管理の運用方法そのものが大きく変わります。

有効期間が短くなることで、更新回数も展開回数も増え、問題が起きたときに原因を調査する時間も短くなります。検証再利用期間も短縮されるため、ドメインと ID の確認頻度も高くなります。

398 日の世界で機能していた手動プロセスでは、47 日のライフサイクルには対応できません。可視性、自動化、明確な責任分担は、もはや選択肢ではなく基盤です。