公開鍵はCSRにどのように含まれていますか?
1つの記事がすべての側面をカバーしているのを見つけることは非常にまれなので、PKIとデジタル証明書のトピックに関する多くの記事を読みました。また、このトピックは最初は混乱しています(この美しい質問は私の最後の読み物です:暗号化、ハッシュ、および署名に関して証明書はどのように機能しますか?)。
私は私の理解のポイントからこのグラフを描きました: https://i.stack.imgur.com/sI7Od.png
2つの質問があります:
公開鍵と暗号文がどのように「パッケージ化」されているのか実際にはわかりません(次のステップに進むために考えられる最善の方法です!)。最後に、*。csrファイルは単なるプレーンです。 base64テキスト、それらは一緒に暗号化されているので、図面のステップの順序は不正確ですか?
送信者のIDを(たとえばWebブラウザーから)確認するには、CSRのコピーが必要ですが、私の理解によれば、証明書にはそのハッシュしかありませんか?
編集:
このビデオは、ANS.1エンコーディングを理解するのに役立つ可能性があります。 https://www.youtube.com/watch?v=EccHushRhWs
私はマルクの答え以下、図を修正し、ここで、とこことでスペックIETF /基本証明書のフィールド:

回答
ダイアグラムにはいくつかの誤解があります。
最も重要なのは、両方のencrypt
ボックスが間違っているということsign
です、彼らは言うべきです。その後、CAに送信されるCSRには、さまざまなフィールド(サブジェクトを含む)とサブジェクトの公開鍵が含まれ、プレーンデータと署名だけを含む暗号文はありません。
RFC2986:PKCS#10:証明書要求構文では、CSRを構築する手順について詳しく説明しています。
The process by which a certification request is constructed involves the following steps:
1. A CertificationRequestInfo value containing a subject
distinguished name, a subject public key, and optionally a
set of attributes is constructed by an entity requesting
certification.
2. The CertificationRequestInfo value is signed with the subject
entity's private key. (See Section 4.2.)
3. The CertificationRequestInfo value, a signature algorithm
identifier, and the entity's signature are collected together
into a CertificationRequest value, defined below.
サブジェクト(あなたの場合:申請者)の公開鍵は、サブジェクト情報と同様に、CSRに逐語的に含まれています。これは、サブジェクトの公開鍵とCAに送信されるすべてのものを使用して署名されます。
ダイアグラム形式ではありませんが、CSRを構築する手順と含まれるデータは次のとおりです。CSRを構築するための正しい手順(ダイアグラム形式ではありません)は次のとおりです。
CertificationRequestInfo
を使用して構築します。Subject Distinguished Name
Subject Public Key
Other attributes
- 使用および特定のアルゴリズムに
Signature
署名しCertificationRequestInfo
て取得しSubject Public Key
ますSignature Algorithm
。 - 以下
CSR
を含めてオブジェクトを作成します。CertificationRequestInfo
Signature
Signature Algorithm
- この
CSR
blobをCAに送信します。
CSRにはまだ平文CertificationRequestInfo
とが含まれていることに注意してくださいSubject Public Key
。
を受信するCSR
と、CAは多かれ少なかれ次のことを行います。
- CSRを解析する
- サブジェクトの公開鍵を使用して、署名がCSRのフィールドと一致することを確認します
- さまざまなフィールドが要件に一致していることを確認します(例:
CN=google.com
ドメインを所有していることを証明せずに要求することはできません) - CSRの一部のフィールド、それ自体のフィールドを使用して証明書を作成する
- (発行者の)秘密鍵を使用して証明書に署名する
最終的な証明書には、サブジェクトフィールドとサブジェクトの公開鍵が引き続き含まれています。
2つの質問に具体的に答えるには:
- 対象者の公開鍵はCSRのフィールドの一つです。暗号化されるものはなく、署名されるだけです。
- サブジェクトフィールドが最後の証明書にコピーされているすべてのクライアントが参照するために、彼らはそこにあります。
RFC5280で証明書フィールドのリストを確認できます。CSRの必要がないため、CSRのハッシュはありません。すべての関連情報は、証明書の独自のフィールドにコピーされました。