その中核にあるのが CA/Browser Forum（以下、CA/ブラウザフォーラム）です。

CA/Browser Forum - Certificate Issuers, Certificate Consumers, and Interested Parties Working to Secure the Web

The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and supplie...

cabforum.org

この記事では、

• CA/ブラウザフォーラムとは何か
• 誰が参加し、どのような議論をしているのか
• 私たち利用者・サイト運営者にどんな影響があるのか
• 現在進行形の重要トピック
• サイト運営者が直面している課題
• そして、今後どこへ向かうのか

を、できるだけ体系的に、かつ実務視点も交えながら整理します。
SSL/TLS証明書を扱う事業者・Web担当者だけでなく、「インターネットを使うすべての人」にとって関係のある話です。

CA/ブラウザフォーラムとは何なのか？

一言で言うと

CA/ブラウザフォーラムとは、
「SSL/TLS証明書の発行・運用ルールを、認証局（CA）と主要ブラウザが共同で決めるための業界団体」
です。

法的な規制機関でも、国際条約でもありません。
しかし、その決定内容は事実上「世界標準」として機能します。

なぜなら、ブラウザ側がそのルールを採用すれば、従わない証明書は “警告が出る” “使えなくなる” からです。

なぜこのフォーラムが必要だったのか

2000年代初頭、SSL証明書の世界は今よりもかなり曖昧でした。

• 認証局ごとに審査基準がバラバラ
• ブラウザは「基本的にCAを信じる」前提
• 問題が起きてから個別対応

この状況では、
「どこまでが安全なのか」「何を満たせば信頼されるのか」
が不透明でした。

そこで

• 証明書を発行する側（CA）
• 証明書を評価・表示する側（ブラウザ）

が同じテーブルにつき、
技術・運用・ポリシーを公開議論する場
として生まれたのがCA/ブラウザフォーラムです。

法律ではないのに、なぜ強制力があるの

CA/ブラウザフォーラムの決定事項は、法律ではありません。
それでも実質的に「守らざるを得ない」理由があります。

理由は非常にシンプルです。

• ブラウザが「このルールを守らない証明書は信頼しない」と決める
• 主要ブラウザが足並みを揃える
• 結果、Webサイトが成立しなくなる

つまり
“ユーザー体験を人質に取った強制力”
が存在するのです。

CA/ブラウザフォーラムの主な参加メンバー

ブラウザベンダー（最も強い発言力）

CA/ブラウザフォーラムにおいて、特に影響力が大きいのが主要ブラウザです。

• Google（Chrome）
• Apple（Safari）
• Mozilla（Firefox）
• Microsoft（Edge）

これらのブラウザは、
「最終的に信頼するかどうかを決める側」
であり、事実上の拒否権を持っています。

認証局（CA）

もう一方の主役が認証局です。

代表的な参加メンバーには、

• DigiCert
• GlobalSign
• Sectigo

などがあります。

CAは

• 証明書を発行する立場
• 実運用の課題を知っている立場

として、現実的な意見を提示します。

バランスは対等ではない

形式上は「共同フォーラム」ですが、
実態としては ブラウザ側の発言力が圧倒的に強い のが現実です。

なぜなら、

• ブラウザは「拒否」できる
• CAは「拒否されたらビジネスが成立しない」

からです。

この非対称性こそが、近年の厳格化を加速させている背景でもあります。

インターネット利用者の立場から見た影響

一般ユーザーにとっての最大のメリット

一般のインターネット利用者にとって、
CA/ブラウザフォーラムの存在は ほぼ意識されません。

しかし、その恩恵は確実にあります。

• なりすましサイトの減少
• 証明書警告の信頼性向上
• HTTPS表示の意味が明確になる

「鍵マークがある＝最低限信頼できる」
という共通理解は、フォーラムの合意の積み重ねによって成立しています。

逆に増えた「警告表示」

一方で、ユーザー体験として増えたのが
警告画面を見る機会 です。

• 証明書期限切れ
• 中間証明書不備
• アルゴリズム非対応

これらはすべて、
CA/ブラウザフォーラムで合意された安全基準が引き上げられた結果
です。

最新のトピック（2024〜2025年）

証明書有効期間の短縮（最重要）

現在、最も大きなトピックが
SSL/TLS証明書の有効期間短縮 です。

• かつて：3年 → 2年
• 現在：最大398日
• 将来案：200日 → 90日

これは「更新が面倒になる」という話ではありません。

• 秘密鍵漏洩リスクの低減
• 不正証明書の早期失効
• 自動化前提の運用への移行

という、セキュリティ設計思想の転換 を意味します。

DCV（ドメイン認証）の厳格化

ドメイン認証（DCV）についても、

• 再利用可能期間の短縮
• 認証方法の制限
• 証明の再検証頻度増加

などが議論・実装されています。

「一度通ったから大丈夫」という時代は終わりつつあります。

証明書透明性（CT）の強化

Certificate Transparency（CT）ログについても、

• ログの多重登録
• 不正検知の迅速化

が求められています。

今、サイト運営者が抱えている問題

「人手運用」が限界に来ている

証明書の更新が年1回以下だった時代は、

• メール通知
• 手作業更新

でも何とかなりました。

しかし、有効期間がさらに短くなれば、

• 年2回
• 年4回
• 将来的には毎月レベル

という更新頻度になります。

これは 人間の運用では破綻する前提 です。

ACME非対応環境の存在

すべての環境が自動化できるわけではありません。

• レガシーシステム
• 制限付きホスティング
• 特殊ネットワーク構成

こうした現場では、
CA/ブラウザフォーラムの決定が 重荷 になるケースもあります。

説明責任の増大

サイト運営者は、

• 「なぜ頻繁に更新が必要なのか」
• 「なぜ費用や作業が増えるのか」

を、
経営層・顧客・利用者に説明する立場にも置かれています。

推奨される補足視点・理解しておきたい論点

CA/ブラウザフォーラムは「善」なのか？

しばしば、

• 「厳しすぎる」
• 「現場を見ていない」

という批判もあります。

しかし、フォーラムの基本思想は一貫しています。

「最も弱い運用を前提に安全性を設計しない」

これは、大規模なインターネットでは合理的な考え方でもあります。

フォーラムの決定は突然ではない

多くの変更は、

• 議論
• 草案
• 投票
• 移行期間

を経て実施されます。

「突然変わった」と感じる場合、
実は 数年前から決まっていた ことも少なくありません。

将来的な方向性

完全自動化が前提になる世界

今後のSSL/TLS運用は、

• ACME
• API連携
• 監視・自動更新

が 前提条件 になります。

「手動更新できないと困る」ではなく、
「手動更新できる環境が例外」になる世界です。

証明書の役割は“見えない基盤”へ

ユーザーはますます証明書を意識しなくなります。

• 警告が出ないのが当たり前
• セキュリティは“感じさせない”

その裏側で、CA/ブラウザフォーラムは
さらに厳しいルールを積み重ねていくでしょう。

サイト運営者に求められる姿勢

これから求められるのは、

• 変化を拒むこと
  ではなく
• 変化を前提に設計すること

です。

CA/ブラウザフォーラムは、
「セキュリティの最終決定者」ではなく
「現実を突きつける存在」
と言えるかもしれません。

おわりに

CA/ブラウザフォーラムは、
表に出ることはほとんどありません。

しかし、

• HTTPSが当たり前であること
• 鍵マークが信頼の指標であること
• インターネットが“そこそこ安全”に使えること

その多くは、このフォーラムの地道な議論と合意によって支えられています。

今後も、
「面倒」「厳しい」「大変」
と感じる変更は続くでしょう。

それでも、
インターネットの信頼を壊さないために
誰かが決めなければならないルール
があることを、少しだけ意識してみてください。

それが、CA/ブラウザフォーラムという存在の本質です。

さらに近年、CA/Browserフォーラムにおいて「MPIC（Multi-Perspective Issuance Corroboration）」という新しい概念が導入され、証明書発行の裏側は静かに、しかし確実に変化しています。このMPICは、従来のDCV手法そのものを否定するものではありませんが、DCVを取り巻く前提条件や考え方に大きな影響を与えています。

本記事では、CA/Browserフォーラムとは何かという基礎から始め、DCVの仕組み、MPICが導入された背景、そしてSSLサーバ証明書の発行実務にどのような影響が出ているのかを、可能な限り平易な言葉で解説していきます。セキュリティ担当者だけでなく、Webサイト運営者、開発者、インフラ担当者にとっても「今後を見据えて知っておくべき内容」としてまとめています。

CA/Browserフォーラムとは何か

CA/Browserフォーラムは、SSLサーバ証明書を発行する認証局（CA）と、主要なWebブラウザベンダーが参加する業界団体です。このフォーラムの最大の役割は、インターネット全体の信頼性を維持するために、証明書発行や運用に関する共通ルールを策定することにあります。

私たちが普段利用しているChromeやEdge、Firefox、Safariといったブラウザは、どの認証局を信頼するかを独自に判断しているように見えますが、その根底にはCA/Browserフォーラムで合意されたガイドラインが存在します。ここで決められたルールに従わない認証局は、最悪の場合、ブラウザから信頼を失い、証明書が警告付きで表示されるという重大な影響を受けることになります。

そのため、CA/Browserフォーラムで議論される内容は、単なる業界内ルールに留まらず、世界中のWebサイト運営に直接的な影響を与える極めて重要なものと言えます。

DCV（ドメイン認証）の基本的な仕組み

SSLサーバ証明書の発行において、最初に行われる重要な工程がDCVです。DCVとは、その証明書を申請している人物や組織が、対象ドメインを正当に管理・使用しているかを確認する手続きです。

この確認が正しく行われなければ、第三者が他人のドメインで証明書を取得し、なりすましサイトを構築することが可能になってしまいます。そのためDCVは、SSL証明書の信頼性を支える最も基本的で重要な要素です。

従来、DCVにはいくつかの方法が用いられてきました。代表的なものとして、Webサーバ上に指定されたファイルを設置する方式、DNSに特定のレコードを追加する方式、指定されたメールアドレスで承認を行う方式などがあります。これらはいずれも「ドメインの管理権限を実際に持っているか」を確認するための手段です。

ここで重要なのは、DCVはあくまで「ドメイン使用権」の確認であり、企業の実在性や担当者の身元確認とは別物であるという点です。この役割分担が、証明書の種類（DV、OV、EV）を理解するうえでも重要になります。

MPICが求められるようになった背景

MPICが導入されるきっかけとなったのは、インターネットを取り巻く環境の変化です。かつては、DNSの名前解決やネットワーク経路は比較的単純で、特定の場所から確認できれば十分と考えられていました。

しかし現在では、CDN、Anycast、リージョン分散、ISPごとのフィルタリングなどにより、同じドメインであっても「見る場所」によって異なる結果が返ることが珍しくありません。このような環境下では、単一の視点から行う確認だけでは、意図しない誤認証や攻撃を防ぎきれないという問題が顕在化してきました。

実際、過去にはBGPハイジャックやDNSの不正操作によって、一時的に偽のコンテンツが正規ドメインとして見えてしまう事例も報告されています。こうしたリスクに対応するため、複数の視点から検証を行い、結果を突き合わせるという考え方がMPICとして整理されました。

MPIC（Multi-Perspective Issuance Corroboration）とは

MPICとは、証明書発行時の検証を単一のネットワーク視点に依存せず、複数の独立した視点から確認する仕組みを指します。ここで言う「視点」とは、地理的・ネットワーク的に異なる場所から行われる検証を意味します。

例えば、HTTPファイル認証であれば、複数の異なる検証拠点から同じURLにアクセスし、すべての拠点で同一の検証ファイルが確認できることをもって、ドメイン使用権が正当に管理されていると判断します。

この考え方により、一時的な経路改ざんや、特定地域のみを狙った攻撃による誤認証リスクを大幅に低減することが可能になります。MPICは、DCVそのものを置き換えるものではなく、DCVの信頼性を高めるための補強策として位置付けられています。

従来のDCVとMPIC対応DCVの違い

以下の表は、従来型DCVとMPICを考慮したDCVの違いを整理したものです。

この表からも分かる通り、MPICは発行のハードルを無意味に上げるものではなく、信頼性を確保するための合理的な進化であると位置付けることができます。

SSLサーバ証明書発行実務への影響

MPICの導入によって、証明書申請者側が行う作業が劇的に増えるわけではありません。しかし、これまで問題なく通っていた認証が、環境によっては通りにくくなるケースが出てきています。

例えば、特定の国やネットワークからのみアクセス制限をかけているWebサーバや、IP制限付きの管理用サーバでは、MPICの複数視点検証に失敗する可能性があります。また、HTTPアクセスを強制的にHTTPSへリダイレクトする設定や、CDN側のキャッシュ挙動によって、検証ファイルが正しく取得できない事例も確認されています。

これらは「MPICが厳しくなった」というよりも、「インターネット全体の標準に合わせて、サーバ設定の前提が見直されている」と捉える方が適切です。

ACMEとMPICの関係

近年主流となっているACMEプロトコルによる自動証明書発行も、MPICの影響を受けています。ACME自体は自動化の仕組みですが、その裏側で行われるDCVは、CA/Browserフォーラムのルールに従う必要があります。

そのため、ACMEクライアントを利用している場合でも、HTTP-01やDNS-01といったチャレンジが、複数視点で正しく確認できる状態でなければ、発行が完了しないケースがあります。自動化されているがゆえに、問題が発生した際に原因が分かりにくくなる点には注意が必要です。

今後の運用で意識すべきポイント

MPICの考え方は、今後さらに厳格化・洗練されていく可能性があります。これは証明書業界だけの話ではなく、インターネット全体の信頼モデルが「単一視点から多視点へ」移行している流れの一部です。

証明書運用においては、特定条件下でのみ成立する設定を前提とするのではなく、よりオープンで標準的な構成を意識することが重要になります。これはセキュリティと利便性のバランスを見直す良い機会とも言えるでしょう。

あとがき

MPICは一見すると難解な専門用語に見えますが、その本質は非常にシンプルです。それは「一方向からの確認だけに頼らず、複数の視点で本当に正しいかを確かめよう」という、極めてまっとうな考え方です。

SSLサーバ証明書は、Webサイトと利用者の信頼関係を支える基盤です。その基盤をより強固にするために導入されるMPICは、今後のインターネットにおいて欠かせない要素となっていくでしょう。

本記事が、証明書運用やWebセキュリティを考えるうえでの一助となれば幸いです。

はじめに

2023年から2025年にかけて、SSL/TLSサーバ証明書業界において、ルート証明書および中間証明書の大規模な更新が相次いで実施されました。業界全体として見ても、これほど広範囲に渡るルート・中間証明書の移行は稀であり、ユーザーや企業にとっては運用上の配慮や再確認が求められる重要な時期と言えます。

この記事では、業界で主に使用されている三大ブランド「DigiCert」「GlobalSign」「FujiSSL」を例に、それぞれの証明書チェーンの構造や更新前後の違い、なぜ今このタイミングでルート更新が必要だったのか、その背景を丁寧に解説していきます。また、ルート認証局（Root CA）選定がWebサイトやサービスの信頼性に与える影響についても触れつつ、更新された階層構造がどのような意図で設計されたかを紐解いていきます。

SSL証明書の基礎と階層構造の重要性

SSL証明書の信頼性は、「ルート証明書（Root CA）」を頂点とする証明書の階層構造（証明書チェーン）によって担保されます。

この構造は以下のように構成されます。

• ルート証明書（Root Certificate）
  信頼の最上位。OSやブラウザに事前にインストールされている。
• 中間証明書（Intermediate Certificate）
  ルート証明書から発行され、エンドエンティティ証明書との間を中継。
• エンドエンティティ証明書（Leaf Certificate）
  Webサーバにインストールされる証明書。

ルート証明書の信頼は絶対的であり、その管理・運用には非常に高いセキュリティ要件が課せられています。

なぜ今、ルート・中間証明書の更新が必要なのか

今回の更新には、以下のような背景があります。

1. セキュリティ要件の厳格化（CA/Bフォーラムの勧告）
   • 有効期間の短縮（825日ルール→90日ルール）
   • 暗号アルゴリズムの進化（RSA 2048bit以上、ECDSA対応など）
2. 古いルート証明書の期限切れとサポート終了
   • 各ルート証明書には有効期限がある。
   • 期限切れ前に新しいルートへ移行することで信頼を継続。
3. 新しいプラットフォームやデバイスへの対応
   • モバイル・IoT環境での互換性確保

これらの要因が重なり、各認証局は自社の証明書体系を見直し、より長期的に安定した信頼性を確保できる新しいチェーンを整備する必要に迫られました。

各ブランドの証明書階層構造の比較

以下に、各ブランドの更新前・更新後の証明書チェーン構造を紹介します。

DigiCert

更新前

• Root：DigiCert Global Root CA
• Intermediate：DigiCert TLS RSA SHA256 2020 CA1

更新後（2024年以降）

• Root：DigiCert Global Root G2（G3）
• Intermediate：DigiCert TLS RSA SHA256 2024 CA1 など

コメント

DigiCertではルートG2やG3への移行を進めており、一部用途において新しい仕様にも対応していますが、構造としては従来と大きく変わらない印象です。一般的なWeb用途では大きな違いを感じにくく、必要十分といったところでしょう。

GlobalSign

更新前

• Root：GlobalSign Root R3
• Intermediate：GlobalSign RSA OV SSL CA 2018 など

更新後

• Root：GlobalSign Root R6
• Intermediate：GlobalSign RSA OV SSL CA 2024 など

コメント

GlobalSignでは、証明書管理の利便性向上に向けてルートR6への切り替えが始まっていますが、階層構造の刷新というよりは従来の踏襲に近い形で、インフラ的なアップデートが中心となっています。

FujiSSL

更新前

• Root：USERTrust RSA Certification Authority
• Intermediate：FujiSSL SHA2 Domain Secure Site CA など

更新後（2025年1月27日以降）

• Root：USERTrust RSA Certification Authority
• CrossRoot：Sectigo Public Server Authentication Root R46
• Intermediate：FujiSSL RSA Domain Validation Secure Server CA 2

※ 上記2つのルート証明書から中間CAを共有する「クロスルート構成」であり、異なるクライアント環境に応じて適切なルートを選択できる柔軟なチェーン設計です。

中間証明書・ルート証明書切り替えのお知らせ | FujiSSL-安心・安全の格安SSLサーバ証明書

いつも弊社のSSLサービスをご利用いただき、誠にありがとうございます。このたび、弊社が提供するSSLサーバ証明書において、中間証明書およびルート証明書の切り替え（変更）を実施いたします。 なぜ切り替えるのか？ 本対応は、最新のセキュリティ基...

www.fujissl.jp

コメント

  ┌ USERTrust RSA Certification Authority
  │
  └ Sectigo Public Server Authentication Root R46
     └─ FujiSSL RSA Domain Validation Secure Server CA 2
        └─ エンドエンティティ証明書（例：*.example.com）

上記のクロスルートの階層構造により、最新のOSやブラウザへの適合と、既存環境との互換性を両立しています。信頼性、将来性、互換性のバランスを図った更新であり、Web環境の多様化に対応した構造と言えます。

階層構造の違いがもたらす実務への影響

• OSやブラウザにおけるルート認識の差異
  • 古いルートはサポート対象外のリスクがある（例：Android 7以前など）
• 証明書チェーン構築の失敗による接続エラー
  • 適切な中間証明書の設置が重要
• 自動更新スクリプトやAPIとの整合性
  • ACMEなどの自動化処理ではチェーンの変更が障害になるケースも

ルート認証局選定と信頼性への影響

エンドユーザーにとっては、どの認証局の証明書を選ぶかがWebサイトの信頼性やアクセス性に直結します。特にルート証明書の普及度や認定状況は以下の点で重要です：

価格面や日本語サポートの観点から見ると、FujiSSLは現実的な選択肢として多くの企業に受け入れられやすい構成です。中堅・中小企業でも導入しやすいバランスが整っており、証明書選定において重要なポイントをおさえている印象です。

おわりに

SSL/TLS証明書の更新において、ルート証明書・中間証明書の理解は不可欠です。今回のような業界全体の動きを受けて、各ブランドはセキュリティ強化と将来性を見据えたチェーンへの移行を進めています。

DigiCertは新しいルートG2やG3への移行を進めていますが、構造的な刷新よりも従来の形式を維持しながらの更新という印象が強く、既存の利用環境を大きく変えることなく対応しているといえます。GlobalSignも同様に、ルートR6を中心とした移行を進めていますが、階層設計としては大きな変化を伴わない構成であり、機能面のアップデートが主軸となっています。

一方でFujiSSLにおいては、異なるルート証明書を併用できるクロスルート構成を取り入れることで、旧環境との互換性を保ちつつ、将来的なブラウザやOSの変化にも柔軟に対応できる仕組みを備えています。信頼性、コスト、互換性、日本語サポートといった実務的な観点を総合的に満たしており、多様な現場で扱いやすい構成が特長です。

証明書の選定においては、単にブランドの知名度だけでなく、自社の利用環境や運用リソース、セキュリティポリシーに合った設計を見極めることが重要です。今後も変化するインターネットの信頼基盤に柔軟に対応するために、最新の証明書階層構造への理解を深め、継続的な見直しと対応を怠らない姿勢が求められます。

SSL証明書の有効期間は、ここ数年で静かに、しかし確実に短縮され続けています。そして今、業界全体が次なる大きな転換点、「90日有効期間の義務化」へと向かおうとしています。これは単なる技術的な仕様変更ではありません。**すべてのWebサイト運営者、証明書発行企業、そしてエンドユーザーにとって根本的な運用の見直しを迫られる“ルールの変化”**です。

本記事では、この動向の背景、予測される影響、そして今から取るべき対応について解説します。

これまでの流れ：有効期間はなぜ短縮されてきたか？

かつてSSL証明書は最長5年間の有効期間を誇っていました。それが、2018年には3年→2年に、2020年9月には最大1年（398日）へと短縮されました。

これは、以下の背景によるものです：

• セキュリティ強化
  長期間の証明書は鍵が漏洩した場合のリスクが高まる
• 証明書の誤発行対策
  短期で更新されれば、誤発行の修正も早くなる
• インフラ更新の促進
  定期的な更新が古い技術の使い回しを防ぐ

このような目的から、有効期間は着実に短縮されてきました。

次に来るのは「90日」— AppleとGoogleが示す方向性

2023年、AppleはSafariやiOSで受け入れるSSL証明書の有効期間について「将来的に90日に短縮する方針」を明言し、Google Chromeも同調する意向を示しました。

現在、AppleやGoogleはCA/Bフォーラム（証明書業界の標準化団体）において有効期間90日制限の議論を進めており、実施は早ければ2025年内〜2026年初頭にも開始される見込みです。

つまり、強制的に「3ヶ月ごとのSSL更新」が必要になる時代が来ようとしています。

なぜ「90日」に？その理由と目的

短縮の狙いは一貫して「セキュリティの強化」です。特に以下の観点が重要です：

• 鍵漏洩リスクの抑制
  → 90日なら仮に秘密鍵が漏洩しても影響は最小限
• 証明書の不正使用防止
  → 不正取得の証明書も短期間で期限切れにできる
• オートメーションの促進
  → 頻繁な更新が手動運用を困難にし、自動化を強制する

実際に何が変わるのか？

仮に90日ルールが正式に施行されれば、以下のような変化が発生します：

現在の運用

• 年1回の更新で十分（1年証明書）

変更後の運用

• 年4回以上の更新が必要
• ドメイン認証（DCV）も3ヶ月ごとに実施
• サーバー設定や証明書の自動再デプロイが必須
• 作業漏れ＝即サイト停止のリスク

一度でも更新作業を忘れれば、証明書失効→ブラウザ警告表示→サイト離脱・信用失墜という悪夢が現実となります。

影響を受けるのは「誰か」ではなく「全員」

これはSSL証明書の契約者だけの話ではありません。影響は以下の全プレイヤーに及びます：

今からできる対応策

以下は今から準備すべき現実的なアクションです：

ACMEプロトコルによる自動更新の導入

Let’s EncryptやSectigo、DigiCertなどが提供するACME対応証明書サービスを利用し、証明書の自動取得・更新を行う仕組みの構築が最優先です。

DevOps・CI/CD連携

証明書更新→Webサーバ再起動→構成反映のフローを自動化する必要があります。

証明書のライフサイクル管理体制の見直し

スプレッドシートでの更新管理は限界。証明書の一元管理ツールや**APIベースの証明書サービス（CaaS）**の導入を検討すべきです。

「1年」はもう長すぎる時代へ

一見、年1回のSSL更新など些細な運用作業に思えるかもしれません。しかし、「それが年4回になった」と考えると話は変わってきます。しかもその作業はセキュリティに直結し、失敗すれば即・信用を失うものです。

今、SSL証明書は“取得して終わり”ではなく、“管理し続けるもの”へと進化しています。変化のスピードは速く、待ってくれません。

最後に：あなたの証明書は、準備できていますか？

この制度変更は「来るかもしれない未来」ではなく、既に規格として議論され、実現に向けて動いている現実です。ギリギリになって慌てる前に、今すぐ証明書運用の棚卸しを行いましょう。

「SSLは設定して終わり」の時代はもう終わりました。これからは「更新し続ける覚悟」が求められるのです。

CA/Browser Forum - Certificate Issuers, Certificate Consumers, and Interested Parties Working to Secure the Web

The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and supplie...

cabforum.org

Google Online Security Blog

The latest news and insights from Google on security and safety on the Internet

security.googleblog.com

Chromeは、ウェブサイトの信頼性とセキュリティを確保するため、認証局（CA）の厳格な審査と監視を行っています。認証局は、ウェブサイトが安全であることを証明するデジタル証明書を発行する組織です。これらの証明書は、ユーザーがアクセスするウェブサイトが信頼できるものであることを保証します。

Entrustとは

Entrustは、デジタル証明書を発行する認証局であり、企業や個人に対してセキュアなオンライン取引を可能にするための証明書サービスを提供しています。Entrustは、SSL/TLS証明書を発行し、ウェブサイトの通信を暗号化することで、データの盗聴や改ざんを防ぐ役割を果たしています。また、企業向けには、電子署名やデジタルID管理などのセキュリティソリューションも提供しています。

今後の影響

ChromeがEntrustを信頼しないと決定したことにより、Entrustが発行した証明書を使用しているウェブサイトは、Chromeユーザーに対して「この接続は安全ではありません」という警告が表示される可能性があります。この警告は、ウェブサイトの信頼性に対するユーザーの信頼を損ない、訪問者数の減少やビジネスへの影響を及ぼす可能性があります。そのため、EntrustはChromeの基準を再評価し、必要な改善を行うことが求められます。

CRL

企業の内部ネットワークで、定期的に更新されるCRLファイルを一括してダウンロードし、各クライアントがローカルに保存されたリストを参照することで、証明書の失効を確認します。この方法はネットワークの負荷を軽減し、安定した環境で有効です。

OCSP

オンラインショッピングサイトでは、ユーザーがクレジットカード情報を入力する際に、SSL証明書の有効性をリアルタイムで確認するためにOCSPを使用します。これにより、即座に失効証明書を検知し、ユーザーの情報を保護します。

CRLとOCSPの対比

将来性について

CA/ブラウザフォーラムは、CRLの利用を縮小し、OCSPの利用を推進する意向を示しています。これは、セキュリティの向上とユーザーエクスペリエンスの改善を目的としています。CRLは、大量の失効情報を含むため、更新が遅れたり、ダウンロードに時間がかかったりすることが問題です。一方、OCSPは特定の証明書のステータスをリアルタイムで確認できるため、ユーザーに即時の応答を提供します。特に、インターネットの普及と高速化が進む現代では、即時性が重要視されます。

また、OCSPにはステープリングという技術もあり、これによりサーバーがOCSPレスポンダーからの最新の失効情報をキャッシュし、クライアントに対して提供することができます。これにより、レスポンス時間がさらに短縮され、セキュリティも向上します。

将来的には、OCSPとそのステープリングの利用がさらに一般化し、CRLは段階的に廃止されると予想されます。これにより、インターネット上の安全性と信頼性が向上し、ユーザーの利便性も高まるでしょう。CAやサービスプロバイダーは、これらの技術の採用と適応に努めることで、セキュアなインターネット環境の構築に寄与することが求められます。