概要
HTTPS（SSL経由/TLS）使用 公開鍵暗号化 ブラウザ通信がインターネット上で転送中に読み取られたり変更されたりしないよう保護するため。 サーバーは、以降のすべてのデータ交換のために暗号化された接続を確立するために使用される公開鍵を訪問ブラウザーに提供します。
ただし、 ワーキング 公開鍵だけでは、それが（さらにはサーバーも）実際に正しいリモートによって所有されていることは保証されません テーマ （すなわち、人、会社または組織）。 マン・イン・ザ・ミドル 攻撃者はネットワークを操作して独自の鍵を提供し、それによってあらゆる通信を危険にさらすことができます。
ブラウザはこれを防止します 認証 を使用するHTTPSサーバー 証明書、それは バインド 個々のサブジェクトへの公開鍵。 バインディングは、信頼されていることによってアサートされます 認証局 （CA）など SSL.com 資格のあるデータベースに対する自動および手動チェックを介して、証明書の所有者候補の身元を確認します。
この信頼関係は、Webユーザーのセキュリティが絶対的ではないことを意味します。 むしろ、セキュリティを保護するために、ユーザーはブラウザーとCAを信頼する必要があります。 したがって、証明書の検証がどのように機能するかを基本的に理解することは、すべてのユーザーの利益になると考えています。
証明書の検証プロセス（標準ドキュメントで詳細に説明） RFC 5280）はかなり複雑です。 この記事では、XNUMXつのパス（ホストのSSL /を検証するブラウザー）に沿って説明します。TLS 証明書）そして、ほとんどのユーザーにとって重要ではない過去の複雑な詳細をナビゲートします。
証明書とX.509形式
証明書はあらゆる点でデジタルファイルです。つまり、情報（署名、キー、発行者など）を保存するには、ファイル形式に従う必要があります。 プライベートながら PKI 構成は、公的に信頼されている証明書の任意の形式を実装できます PKIs（つまり、ブラウザによって信頼されているもの）は、RFC 5280に準拠している必要があります。 X.509 v3 形式でダウンロードすることができます。
X.509 v3を使用すると、使用制限やポリシー情報などの追加データを証明書に含めることができます。 エクステンション、各拡張子はどちらか 重大な or 重要ではない。 ブラウザは無効または認識されていない重要でない拡張機能を無視できますが、重要な拡張機能をすべて処理して検証する必要があります。
認定パスとパス処理
CAは秘密キーを使用して、発行されたすべての証明書に暗号で署名します。 このような署名は、証明書が特定のCAによって発行されたものであり、署名後に変更されなかったものであることを証明できます。
CAは、自己発行の証明書（ ルート）対応する公開鍵。 CAはルートを作成、管理、利用するために厳格に管理および監査された手順を遵守する必要があり、公開を最小限に抑えるため、通常はルートを使用して発行 中間の 証明書。 これらの中間体は、顧客の証明書を発行するために使用できます。
ブラウザーには、信頼されたルートの組み込みリストが付属しています。 （これらは、ブラウザーの厳格な基準に合格したCAからのルートです。）証明書を検証するために、ブラウザーは一連の証明書を取得し、それぞれがシーケンス内の次の証明書に署名し、署名CAのルートをサーバーのルートに接続します。証明書。
この一連の証明書は、 認定パス。 パスのルートは、 トラストアンカー サーバーの証明書は、 葉っぱ or エンドエンティティ 証明書。
パス構築
多くの場合、ブラウザは、特定の証明書に対して有効なパスを見つけるまで、複数の証明書パスを考慮する必要があります。 パスに既知のアンカーに適切に「チェーン」する証明書が含まれている場合でも、パスの長さ、ドメイン名、証明書の使用、またはポリシーの制限により、パス自体が拒否される場合があります。
すべての可能なパスの構築と評価は、ブラウザが遭遇するすべての新しい証明書に対して実行される高価なプロセスです。 ブラウザは、拒否される候補パスの数を最小限に抑えるためにさまざまな最適化を実装していますが、そのような詳細を掘り下げることは、この記事の範囲をはるかに超えています。
パスの検証
候補の認証パスが構築されると、ブラウザは証明書に含まれる情報を使用してそれを検証します。 ブラウザーがトラストアンカーによって直接署名された証明書から始めて、各証明書の対応する秘密鍵がパスの次の証明書を発行するために使用され、リーフ証明書に至るまで暗号で証明できる場合、パスは有効です。
証明書パス検証アルゴリズム
RFC 5280は、 標準アルゴリズム X.509証明書の認証パスを検証するためにブラウザが従います。
基本的に、ブラウザーはトラストアンカー（ルート証明書）で始まるパス内のすべての証明書を反復処理し、各証明書の基本情報と重要な拡張機能を検証します。
手順がパスの最後の証明書でエラーなしに終了した場合、パスは有効として受け入れられます。 エラーが発生した場合、パスは無効としてマークされます。
基本的な証明書の処理
拡張機能に関係なく、ブラウザは常に署名や発行者などの基本的な証明書情報を検証する必要があります。 次のセクションでは、ブラウザが実行する一連のチェックを示します。
1.ブラウザは証明書の整合性を検証します
この 署名 証明書の通常の公開キー暗号化を使用して検証できます。 署名が無効な場合、証明書は発行後に変更されたと見なされ、拒否されます。
2.ブラウザが証明書の有効性を確認します
証明書の 有効期間 署名CAがそのステータスに関する情報を維持することを保証する時間間隔です。 ブラウザーは、妥当性検査の日時の前または後に有効期間が終了する証明書を拒否します。
3.ブラウザが証明書の失効ステータスを確認します
証明書が発行されると、その有効期間全体にわたって使用されることが期待されます。 もちろん、さまざまな状況により、証明書が自然に期限切れになる前に無効になる場合があります。
そのような状況には、サブジェクトが名前を変更したり、秘密鍵が侵害された疑いがあるなどがあります。 このような場合、CAは対応する証明書を取り消す必要があり、ユーザーはCAを信頼して、証明書の失効ステータスをブラウザーに通知します。
RFC 5280 CAはこの目的で失効リストを使用することをお勧めします。
証明書失効リスト（CRL）
CAは定期的に、署名されたタイムスタンプ付きの失効した証明書のリストを発行します。 証明書失効リスト （CRL）。 CRLは公開されているリポジトリで配布され、ブラウザは証明書を検証するときにCAの最新のCRLを取得して参照できます。
この方法のXNUMXつの欠点は、失効の時間の細分性がCRLの発行期間に制限されることです。 現在発行されているすべてのCRLの更新がスケジュールされた後にのみ、ブラウザーに失効が通知されます。 署名するCAのポリシーに応じて、これにはXNUMX時間、XNUMX日、または最大でXNUMX週間かかる場合があります。
オンライン証明書ステータスプロトコル（OCSP）
失効ステータス情報を取得する方法は他にもありますが、最も一般的なのは オンライン証明書ステータスプロトコル （OCSP）。
標準文書に記載 RFC6960、OCSPにより、ブラウザはオンラインOCSPサーバー（別名、 応答者）。 適切に構成すると、OCSPはより迅速になり、上記のCRL更新の待ち時間の問題を回避します。 加えて、 OCSP Stapling パフォーマンスと速度が向上します。
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年に、研究者が実証するまで、ブラウザは認証パスの長さを無視していました プレゼンテーション、彼がWebサイトのリーフ証明書を使用して大規模なeコマースWebサイトの有効な証明書を偽造した方法。
8.ブラウザはキーの使用を確認します
「キー使用法」拡張は、証明書に含まれるキーの目的を示します。 このような目的の例には、暗号化、署名、証明書の署名などがあります。 ブラウザは、CRL署名専用のキーを持つサーバー証明書に遭遇するなど、キーの使用制限に違反する証明書を拒否します。
9.ブラウザは残りの重要な拡張機能をすべて処理し続けます
上記の拡張機能を処理した後、ブラウザは、現在の証明書がクリティカルとして指定している残りのすべての拡張機能を検証してから、次の拡張機能に進みます。 ブラウザがエラーなしでパスのリーフ証明書に到達すると、パスは有効として受け入れられます。 エラーが発生した場合、パスは無効としてマークされ、安全な接続が確立されません。
まとめ
ワールドワイドウェブは、相互に接続され、絶えず進化する可動部分の複雑なシステムです。 したがって、ブラウザのセキュリティは解決された問題ではありません。この記事が、ここで見たXNUMXつのコンポーネントの複雑さについてもある程度の洞察を提供してくれることを願っています。 信頼は、オンラインでの安全を確保する上で重要な役割を果たします。そのため、CAの証明書ポリシーについて詳しくお問い合わせください。 （自由にレビューしてください SSL.comのポリシーはこちら、 実際には。）
SSL.comをお選びいただきありがとうございます。 より安全な インターネットは 優れた インターネット。
