クライアントにCAの公開鍵がない場合、クライアントはSSL証明書がCAによって署名されたことをどのようにして知るのですか？

Question

私はまだSSL/TSLがどのように機能するかを学んでいるので、この質問が非常に基本的なものである場合は謝罪してください。

サーバーがクライアントにSSL証明書を提供することを理解しています。これにはCAの署名が含まれています。また、クライアントには通常、信頼する認証局のリストがあることも理解しています。しかし、SSL証明書が、クライアントが認識していないCAによって署名されている場合はどうなりますか？その後、クライアントはどのように証明書を検証しますか？

psmears · Accepted Answer

クライアントが証明書を検証する場合、3つの可能性があります。

証明書は、クライアントが既に信頼している（公開鍵を知っている）CAによって署名されています。この場合、クライアントは証明書を有効なものとして扱います。
証明書は、クライアントがまったく認識していないCAによって署名されています。この場合、クライアントは証明書を無効として扱います（そして、ブラウザーはページをロードする代わりに警告メッセージを表示する可能性があります）。
証明書は、クライアントが知らないCAによって署名されていますが、クライアントには行うが知っているCAによって署名された証明書があります。（この場合、サーバーは通常、独自の証明書と、「中間CA」と呼ばれる、証明書に署名したCAの証明書の両方を送信する必要があります）。中間CAの証明書は、クライアントが既に信頼しているCAによって署名されているため、信頼できることがわかり、サーバーの証明書は中間CAによって署名されているため、クライアントもそれを信頼できることがわかります。

CA証明書は「特別」であることに注意してください-信頼できるCAによって署名された証明書があるからといって、他の証明書に署名してクライアントに信頼してもらうことができるわけではありません。。

Numeron · Answer

そうではありません。無効な証明書であるかのように扱われます。

たとえば、誰でも証明書に自己署名し、基本的に自分自身のCAとして機能することができますが、証明書はブラウザによって信頼されていないため、ユーザーはその旨の警告を受け取ります。

Bruno · Answer

これにはすでにいくつかの良い答えがありますが、完全を期すために、完全なチェーンを常にクライアントに提示する必要はないことを付け加えておきます。

これがどのように機能するかの例として、ルートとエンドエンティティを含むFOUR（！）証明書を含む証明書チェーンを次に示します（このような設計はお勧めしません）。

メモとして、ファイルエクスプローラーで.cer形式の証明書ファイルをダブルクリックし、「証明書パス」を選択することで、任意のWindowsマシンでこのプロパティページを取得できます

クライアントがWebサイトにアクセスするとき、このチェーンを確認する方法が2つあります。 Webサイトは、Webサイト、発行者、およびポリシー*証明書をクライアントに直接提示できます。または、一部のクライアントは、チェーン内の次の証明書をダウンロードするためのアドレスを提供する証明書の拡張プロパティを追跡できます。

少なくともMicrosoft証明書クライアントの場合、この証明書拡張は「Authority Information Access」（AIA）と呼ばれ、CDP（CRL配布ポイント）フィールドに同様にフォーマットされ、チェーン内の次の証明書の場所を決定するために使用できます。以下のように、証明書パスがあるのと同じウィンドウの[詳細]タブで確認できます。

CDPおよびAIAの詳細情報ここ。

したがって、この例では、チェーン全体が前もって提示されていないシナリオでクライアント検証がどのように機能するかを次に示します。

クライアントはhttps経由でwebsite.comにアクセスし、「Webサイト」証明書が提示されます。
クライアントは、これが信頼されたルートではなく、自己署名されていないことを確認します。「発行元」証明書のAIAを見つけると、この証明書をダウンロードし、この証明書の公開鍵が「Webサイト」証明書に署名したことを確認します。
クライアントは、「発行元」の証明書が信頼できるルートではなく、自己署名されていないことを確認します。「ポリシー」証明書のAIAを見つけると、この証明書をダウンロードし、この証明書の公開鍵が「発行者」証明書に署名したことを確認します。
クライアントは、「ポリシー」証明書が信頼されたルートではなく、自己署名されていないことを確認します。ただし、この証明書の発行者が信頼されたルートの1つであることがわかり、ルート証明書の公開キーが「ポリシー」証明書に署名されていることを確認します。

チェーン内の証明書ごとに、CDPの証明書失効リスト（CRL）がチェックされ、失効がないことを確認します。

クライアントが信頼できる証明書を見つけた場合、「Webサイト」証明書は信頼されたルートによって発行されたものであり、取り消されていないことが確認されています。その他のチェック（有効期間など）でも、証明書が無効になる可能性があります。

いずれかの時点でクライアントが自己署名した信頼されていない証明書を見つけた場合、「Webサイト」証明書は信頼されたルートによって発行されたものとして検証されていません。通常、クライアントはこの時点で警告をポップアップします。

はい。これは、自己署名されていない信頼できる証明書を持っている可能性があることを意味しますが、一般的なシナリオではありません。

*クライアントがルートを信頼する場合は、ルート証明書のコピーがすでにあるはずです-信頼されたルート証明機関のリストに手動で追加する必要があります！（これは、一部のルートCAがまだSHA1であり、それが問題ではない理由でもあります）。ただし、someソフトウェアはsomeソフトウェアであるため、ルート証明書は引き続き表示されます冗長なルートを含む完全なチェーンを期待します。証明書とやり取りするソフトウェアを扱うときはいつでも、この種の無意味さをしばしば期待してください。

補遺-ルートが信頼される方法

ルートは手動で信頼されていると述べましたが、ほとんどの場合、信頼されたルート証明書は非手動のメカニズムによってマシンに配布され、ソフトウェアのすべてのバージョンにバンドルされるか、自動更新で配布されることがよくあります。以下は、主要なWebサイトインターフェイスの証明書使用ソフトウェアの一般的な方法とポリシーのリストです。

Microsoft Trusted Root Certificate Program Updates

最新の証明書パッケージ here を取得できます。
Active Directoryドメインベースの配布（リンクされた記事では、信頼されたルートをローカルのWindowsコンピューターに手動で追加する方法についても説明しています。）

上記の方法は両方とも、IEおよびEdgeを含む複数のアプリケーションによって使用されるWindows OS証明書ストアを更新します。

Mozillaルートストアポリシー
ルート証明書ポリシー-Chromiumプロジェクト（google chromeを含む）

MozillaとChromeはどちらも、OSとは独立して証明書を信頼し（独自の信頼されたルートストアを効果的に維持）、アプリケーションで構成された設定に応じてOSの信頼されたルートストアにサブスクライブできます。特定のOS。

アプリ固有のルートストアにある信頼されたCAは、信頼されたルートプログラムの支援に基づいて追加および削除されます。