イントロダクション
HTTPS（SSL経由/TLS）使用 公開鍵暗号化 ブラウザ通信がインターネット上で転送中に読み取られたり変更されたりしないよう保護するため。 サーバーは、以降のすべてのデータ交換のために暗号化された接続を確立するために使用される公開鍵を訪問ブラウザーに提供します。
ただし、 ワーキング 公開鍵だけでは、それが（さらにはサーバーも）実際に正しいリモートによって所有されていることは保証されません テーマ (つまり、個人、会社、または組織)。 マン・イン・ザ・ミドル 攻撃者はネットワークを操作して独自の鍵を提供し、それによってあらゆる通信を危険にさらすことができます。
ブラウザはこれを防止します 認証 を使用するHTTPSサーバー 証明書、それは バインド 個々の主体への公開鍵。この結合は、信頼できるc証明機関 （CA）など SSL.com 資格のあるデータベースに対する自動および手動チェックを介して、証明書の所有者候補の身元を確認します。
この信頼関係は、ウェブユーザーのセキュリティが絶対的なものではないことを意味します。むしろ、ユーザーはブラウザとCAを信頼してセキュリティを保護する必要があります。したがって、証明書の検証の仕組みについて基本的な理解を持つことは、すべてのユーザーにとって重要です。
証明書の検証プロセス（詳細は標準文書に記載） RFC 5280）はかなり複雑です。 この記事では、XNUMXつのパス（ホストのSSL /を検証するブラウザー）に沿って説明します。TLS 証明書）そして、ほとんどのユーザーにとって重要ではない過去の複雑な詳細をナビゲートします。
注意： 2024年XNUMX月現在、 RFC 9618、インターネット技術タスクフォース（IETF）文書は、RFC 509 の X.5280 デジタル証明書のポリシー制約を検証するためのアルゴリズムを更新しました。
証明書とX.509形式
証明書はあらゆる点でデジタルファイルであるため、情報（署名、鍵、発行者など）を保存するためにファイル形式に従う必要があります。プライベート証明書は PKI 構成は、公的に信頼されている証明書の任意の形式を実装できます PKI（つまり、ブラウザによって信頼されるもの）は、RFC 5280に準拠する必要があり、 X.509 v3 形式でダウンロードすることができます。
X.509 v3を使用すると、使用制限やポリシー情報などの追加データを証明書に含めることができます。 エクステンション、各拡張子はどちらか 重大な or 重要ではない. クライアントが認識できない、重要でない拡張機能に遭遇した場合、それを無視することができます。拡張機能が重要であり、認識できない、または処理できない場合は、証明書を拒否する必要があります。
認定パスとパス処理
CAは発行するすべての証明書に秘密鍵を使って暗号署名します。このような署名は 暗号的に 証明書が特定の CA によって発行され、署名後に変更されていないことを証明します。
CAは、自己発行の証明書（ ルート) に対応する公開鍵を取得します。 CAは、ルートを作成、管理、および使用するために、厳格に管理され監査された手順を遵守する必要があり、リスクを最小限に抑えるために、通常はルートを使用して発行します。 中間の 証明書。 これらの中間体は、顧客の証明書を発行するために使用できます。 ルートCA証明書は自己署名されており、秘密鍵は厳格な手順で保護されています。発行は通常、ルートCAから直接ではなく、仲介者を介して行われます。
ブラウザーには、信頼されたルートの組み込みリストが付属しています。 （これらは、ブラウザーの厳格な基準に合格したCAからのルートです。）証明書を検証するために、ブラウザーは一連の証明書を取得し、それぞれがシーケンス内の次の証明書に署名し、署名CAのルートをサーバーのルートに接続します。証明書。
この一連の証明書は、 認定パス。 パスのルートは、 トラストアンカー サーバーの証明書は、 葉っぱ or エンドエンティティ 証明書。
パス構築
ウェブブラウザやソフトウェアクライアントは、多くの場合、複数の候補トラストアンカー（例えば、クロスサインなど）を構築し、AIAを介して不足している中間証明書を取得してチェーンを完成させます。パスに既知のアンカーに正しく「連鎖」する証明書が含まれている場合でも、パスの長さ、ドメイン名、証明書の用途、またはポリシーの制限により、パス自体が拒否される可能性があります。
すべての可能なパスの構築と評価は、ブラウザが遭遇するすべての新しい証明書に対して実行される高価なプロセスです。 ブラウザは、拒否される候補パスの数を最小限に抑えるためにさまざまな最適化を実装していますが、そのような詳細を掘り下げることは、この記事の範囲をはるかに超えています。
パスの検証
候補の認証パスが構築されると、ブラウザは証明書に含まれる情報を使用してそれを検証します。 ブラウザーがトラストアンカーによって直接署名された証明書から始めて、各証明書の対応する秘密鍵がパスの次の証明書を発行するために使用され、リーフ証明書に至るまで暗号で証明できる場合、パスは有効です。
ベースライン要件では、 すべての可能なパス be バイト単位で同一これにより、信頼性の高いパスの構築が簡素化されます。
証明書パス検証アルゴリズム
前述の通り、2024年XNUMX月時点で、 RFC 9618、インターネット技術タスクフォース（IETF）文書は、RFC 509 の X.5280 デジタル証明書のポリシー制約を検証するためのアルゴリズムを更新しました。基本的に、ブラウザは信頼アンカー (ルート証明書) から始まるパス内のすべての証明書を反復処理し、各証明書の基本情報と重要な拡張機能を検証します。
手順がパスの最後の証明書でエラーなしに終了した場合、パスは有効として受け入れられます。 エラーが発生した場合、パスは無効としてマークされます。
基本的な証明書の処理
拡張機能に関係なく、ブラウザは常に署名や発行者などの基本的な証明書情報を検証する必要があります。 次のセクションでは、ブラウザが実行する一連のチェックを示します。
1.ブラウザは証明書の整合性を検証します
その 署名 証明書の通常の公開キー暗号化を使用して検証できます。 署名が無効な場合、証明書は発行後に変更されたと見なされ、拒否されます。
2.ブラウザが証明書の有効性を確認します
証明書の 有効期間 署名CAがそのステータスに関する情報を維持することを保証する時間間隔です。 ブラウザーは、妥当性検査の日時の前または後に有効期間が終了する証明書を拒否します。
3.ブラウザが証明書の失効ステータスを確認します
証明書が発行されると、その有効期間全体にわたって使用されることが期待されます。 もちろん、さまざまな状況により、証明書が自然に期限切れになる前に無効になる場合があります。
そのような状況には、サブジェクトが名前を変更したり、秘密鍵が侵害された疑いがあるなどがあります。 このような場合、CAは対応する証明書を取り消す必要があり、ユーザーはCAを信頼して、証明書の失効ステータスをブラウザーに通知します。
証明書失効リスト（CRL）
証明書失効リスト (CRL) は、2024 年現在、証明書失効チェックの業界標準となっています。CA は、ブラウザーがダウンロードしてローカルにキャッシュできる、署名されタイムスタンプが付けられた失効した証明書のリストを定期的に発行します。
以前は CRL はリアルタイム チェック方法よりも効率が悪いと考えられていましたが、業界では CRL が推奨されるアプローチとなる大きな利点を認識しています。
- 強化されたプライバシーCRLは、閲覧パターンを明らかにする可能性のある特定の証明書について外部サーバーに問い合わせる必要性を排除することで、ユーザーのプライバシーを保護します。
- オペレーション効率向上: CAは高可用性のリアルタイム応答サービスを維持することなく、失効をより効率的に管理できます。
- インフラストラクチャコストの削減: 24時間7日のOCSP対応者の必要性を排除することで、運用上のオーバーヘッドを大幅に削減します。
- キャッシュの改善: 最新のブラウザはCRLを効率的にキャッシュして更新できるため、以前はリアルタイム方式が有利だった遅延の懸念を最小限に抑えることができます。
3月現在、2024、 CA/ブラウザフォーラムは、すべての公的に信頼されたCAにCRLを提供することを義務付け、他の失効方法はオプションとしています。いくつかの主要な証明機関は、CRL のみのアプローチを採用し、代替失効サービスを中止しています。
オンライン証明書ステータスプロトコル（OCSP）
オンライン証明書ステータスプロトコル（OCSP）は、 RFC 6960、 ブラウザがOCSPサーバー（レスポンダー）に特定の証明書について問い合わせることで、リアルタイムの証明書失効チェックを提供するように設計されました。OCSPは2010年代に定期的なCRLダウンロードの改良として広く採用されましたが、業界ではこのアプローチから大きく離れてしまいました。
- OCSPは、公的に信頼されたCAにとってオプションとなりました（2024年XNUMX月発効）。OCSPの重要性は 衰退する; 例えば、 暗号化しよう 2025年XNUMX月にOCSP URLを削除し、 2025年8月.
- 一部のブラウザではOCSPチェックが無効になっているか、セキュリティ上のメリットが最小限にしか提供されない方法で実装されています。
OCSP Stapling: と呼ばれる変種 OCSP Stapling サーバーがOCSPレスポンスを直接含めるいくつかのシナリオでは依然として有用である。 TLS ハンドシェイクにより、OCSPレスポンダへの個別のクライアントクエリを回避できます。ただし、これには特定のサーバー設定が必要です。Staplingはほとんどのサーバー/CDNでサポートされていますが、大規模なCAがOCSPを廃止するにつれて、その有用性は低下しています。
これがブラウザで実際にどのように機能するか: 15年2024月2025日以降、CA/Bフォーラムは公的に信頼されているCAに対し、CRLの公開を義務付けていますが、OCSPは任意です。最新のブラウザは一般的に、OCSPを照会したり、サイトごとにCRLをダウンロードしたりしません。代わりに、CAが公開したCRLから構築された集約メカニズムを使用します。ChromeのCRLSetsとFirefoxのCRLiteは、プライバシーを保護しながら高速に失効データをクライアントに配信します。その結果、パブリックWebにおけるOCSPの役割は縮小しています。例えば、Let's Encryptは2025年XNUMX月にOCSP URLを削除し、XNUMX年XNUMX月にはOCSPレスポンダーを停止しました。
4.ブラウザは発行者を確認します
証明書は通常、次のXNUMXつのエンティティに関連付けられています。
クライアントは、パス内の各証明書が前の証明書の公開キーによって署名されていること、および発行者/サブジェクト名がパスに沿って正確に一致していることを確認します。 セキュリティを強化するために、ほとんどの PKI 実装では、発行者の鍵が現在の証明書に署名した鍵と同じであることも検証します。（ただし、ルート証明書は自己発行されるため、トラストアンカーの場合はこの限りではありません。つまり、ルート証明書とサブジェクトは同じです。）
制約処理
X.509 v3形式を使用すると、CAは、各証明書を検証して重要な拡張機能として使用する方法に関する制約または制限を定義できます。 パス内のすべての証明書は、後続のすべての証明書が従わなければならない追加の制約を課す可能性があります。
証明書の制約は、エンタープライズSSLソリューションでは非常に一般的ですが、平均的なインターネットユーザーにはほとんど影響しません。 機能上の制約はいくつかの運用上の目的に役立ちますが、それらの最も重要な用途は、既知のセキュリティ上の懸念を軽減することです。
5.ブラウザは名前の制約をチェックします
個人所有の（ただし公的に信頼されている）中間CAと適切な 名前の制約 名前制約は、組織に証明書の管理と発行に関するきめ細かな制御を提供します。証明書は、企業または組織のドメイン名の特定のドメインまたはドメインツリー（サブドメインを含む）に限定できます。名前制約は、公的に信頼されたCAから購入した中間CA証明書によく使用され、中間CAがサードパーティのドメイン（例： google.com).
6.ブラウザはポリシーの制約をチェックします
証明書ポリシーは、CAが発行する法的文書であり、証明書を発行および管理するためにCAが従う手順を公式に詳述しています。 CAはXNUMXつまたは複数のポリシーに基づいて証明書を発行する場合があり、これらへのリンクは発行された各証明書に含まれているため、証明書を信頼する前に証明書利用者はこれらのポリシーを評価できます。
法的および運用上の理由から、証明書は、適用できるポリシーに制限を課す場合があります。 証明書に重要なポリシー制約が含まれていることが判明した場合、ブラウザーは続行する前にそれらを検証する必要があります。 （ただし、重要なポリシーの制約が現実の世界で発生することはめったにないため、この記事の残りの部分では無視されます。）
7.ブラウザは基本的な制約（別名パス長）をチェックします
X.509 v3形式では、発行者は証明書がサポートできる最大パス長を定義できます。 これにより、各証明書を証明書パスに配置できる距離を制御できます。 これは実際に重要です– 2009年に、研究者が実証するまで、ブラウザは認証パスの長さを無視していました プレゼンテーション彼は、自身のウェブサイトのリーフ証明書を使用して、大規模な電子商取引ウェブサイトの有効な証明書を偽造した。
8.ブラウザはキーの使用を確認します
「キー使用法」拡張は、証明書に含まれるキーの目的を示します。 このような目的の例には、暗号化、署名、証明書の署名などがあります。 ブラウザは、CRL署名専用のキーを持つサーバー証明書に遭遇するなど、キーの使用制限に違反する証明書を拒否します。
9.ブラウザは残りの重要な拡張機能をすべて処理し続けます
上記の拡張機能を処理した後、ブラウザは、現在の証明書がクリティカルとして指定している残りのすべての拡張機能を検証してから、次の拡張機能に進みます。 ブラウザがエラーなしでパスのリーフ証明書に到達すると、パスは有効として受け入れられます。 エラーが発生した場合、パスは無効としてマークされ、安全な接続が確立されません。
最新の証明書管理：有効期限の短縮と自動化
SSL /TLS 近年、業界はいくつかの変化を経験し、証明書の発行と管理の方法が根本的に変化しました。これらの変化を理解することは、 PKI 管理者、IT プロフェッショナル、および/またはデジタル証明書を扱うその他のユーザー。
証明書の有効期間の短縮
2025年XNUMX月、CA/ブラウザフォーラムは画期的な決定（投票用紙 SC-081v3) により、段階的に証明書の有効期間が大幅に短縮されます。
- 現在（2026年XNUMX月まで）：最長398日（約13ヶ月）
- 2026 年 3 月 15 日: 最大200日
- 2027 年 3 月 15 日: 最大100日
- 2029 年 3 月 15 日: 最大47日
ドメイン制御検証（DCV）の変更
証明書の有効期限とともに、ドメイン検証情報の再利用期間も短縮されています。
- 2026年3月: 最大200日間再利用可能
- 2027年3月: 最大100日間再利用可能
- 2029年3月: 最大10日間再利用可能
つまり、組織はドメインの所有権をより頻繁に検証する必要があり、実用的な証明書管理には自動化が不可欠になります。
これらの変更が重要な理由
セキュリティ上の利点:
- 証明書の有効期限が短くなると、鍵が侵害されたときに危険にさらされる期間が短縮されます。
- より頻繁な検証によりドメイン所有権が最新に保たれます
- ウェブ全体にわたるセキュリティ改善のより迅速な展開
運用上の影響:
- 手動での証明書管理は事実上不可能になる
- 組織は自動化された証明書ライフサイクル管理を実装する必要がある
- より頻繁なドメイン検証手順が必要
自動化の要件
これらの変更により、証明書の自動化は有益であるだけでなく、不可欠になります。組織は以下の点を強く検討する必要があります。
- 実施する ACME (自動証明書管理環境) または同様のプロトコル
- 配備します 証明書ライフサイクル管理ソリューション
- 頻繁な更新と検証のためのインフラストラクチャを準備する
- 証明書の有効期間の短縮への移行に備える
証明書の透明性の統合
最新のブラウザでは、発行されたすべての証明書の公開かつ監査可能な記録を提供する証明書透明性（CT）ログの要求や検証がますます増えています。これは、以下の検出に役立ちます。
- 誤って発行された証明書
- 不正な証明書の発行
- CAコンプライアンスの問題
結論
デジタル環境は依然として相互接続されたコンポーネントの複雑なシステムであり、ブラウザのセキュリティは次のような開発が活発に行われている分野です。
- 証明書の有効期間の短縮: 業界は47年までに証明書の有効期間を2029日に延長する方向へ進んでおり、実用的な証明書管理には自動化が不可欠となっている。
- 失効方法の変更OCSPからCRLへの回帰は、業界がユーザーのプライバシーと運用効率を優先していることを反映している。
- より厳格なCA監督: ブラウザはコンプライアンスの強制と、パフォーマンスの低い認証局からの信頼の削除に積極的になっている。
これらの変更は、より自動化され、プライバシーとセキュリティに配慮した証明書管理への根本的な転換を表しています。組織は、証明書の有効期間の短縮と更新プロセスの自動化に向けて、今から準備を始める必要があります。
信頼は、ユーザーのオンライン安全確保において引き続き重要な役割を果たします。これらの進化する標準について最新情報を入手し、認証局のポリシーとコンプライアンス記録を確認することをお勧めします。これらの変更が示すように、証明書エコシステムはセキュリティとプライバシー保護の強化に向けて積極的に適応しています。
証明書管理のベストプラクティスとSSL.comの業界の変化に対するアプローチに関する最新情報については、当社の 証明書比較ページ.
SSL.comをお選びいただきありがとうございます。 より安全な インターネットは 優れた インターネット。
