私はこのことを理解しているかもしれませんが、詳細が正しいことを確認したいと思います。証明書の高レベルの実装や、暗号化などの数学レベルの実装については多くの情報がありますが、低レベルの詳細についてはあまり知りませんでした。
私は理解をまとめました。できる限りまとめることができますが、何らかの方法で詳細を間違えたと確信しています。それらのエラーが何であるか教えていただけますか? (そして、私が省略したことを意味するわけではありません。私はしないでください CRLやX.509形式などについて話し合いたいと思います。それが実装です。私が気にするのはプロセスの半理想化された理解。これが私の記事です。
前もって感謝します。
認証局(CA)は、公開鍵と秘密鍵のペアを持ち、他の人がIDを検証するために信頼する組織です。 Alice(alice.com)がCAによって署名されたデジタル証明書を必要とする場合、彼女は公開鍵と秘密鍵のペアを生成します。彼女は、FQDNや個人のメールアドレスなどの識別情報を含むドキュメントを作成し、秘密鍵で暗号化します。彼女はこの暗号化されたドキュメントを自分の公開鍵と一緒にパッケージ化します。これは証明書署名要求(CSR)です。
彼女はCSRをCAに送信し、IDの確認を要求します。彼らは公開鍵を使用してドキュメントを復号化し、彼女がそのペアの公開鍵と秘密鍵の両方を保持していることを証明します。証明書の目的(電子メールアドレスを認証するか、Webサーバーを認証するか)に応じて、自動化されたものから技術的なものまで、さまざまな方法で彼女の身元を確認することができます。他の人が証明書に入れてほしい信頼のレベル。
CAが申請者の身元を確認した後、彼らは彼女の識別情報(彼女が提出したものと同一である場合もない場合もある)と彼女の公開鍵を含むドキュメントを作成し、ハッシュし、そのハッシュを秘密鍵で暗号化します。署名といくつかのメタデータ(CAが生成したものなど)がドキュメントに付加され、その結果が彼女の証明書になります。
ボブがアリスが本人であると主張している人物であることを確認したいとします。彼女は彼に証明書を提供し、彼はどのCAが証明書を生成したかを決定します。彼はCAを信頼しているため、自分のシステムに公開鍵が保存されています。彼はCAの公開鍵を使用して署名を確認できます。CAの公開鍵を使用してハッシュを復号化し、ハッシュも自分で計算します。値が一致する場合、彼はドキュメントが改ざんされておらず、CAがアリスの身元を保証していることを知っています。
中間CAを持つことが可能です。この場合、中間CAの証明書はユーザーの証明書を発行し、上位CAによって署名された独自の証明書を持っています。ユーザーの証明書が他のユーザーから信頼されるようにするには、署名のチェーンが信頼できるルートCAで終わる必要があります。
あなたの記事はチェックアウトします。 1ニット:
dave_thompson_085mentions なので、暗号化と署名は同じ操作ではありません。 textbookRSAでは同じように実装できますが、同じであることを意味しません。実際、X.509はECDSAをサポートしており、署名はまったく異なります。