HTTPSについての就職の面接で最近質問され、私の知識がその領域で曖昧であると認めましたが、とにかくそれをクラックしました、問題は誰かがサーバーに接続したときに人またはサービスが言うことをどのように知っているかでした彼らは誰だと彼らは言うのですか?どうすればそれらを信頼できますか?私はあなたがCAから証明書を与えられると答えました、そしてこれは接続が正当であるという情報を含んでいます、そして彼らがこの証明書から彼らが誰であると彼らが誰であるかをあなたがどうやって知っているかについてもっと尋ねるように彼らに要求したのでこれは明らかに満足できるものではありませんでしたか?私の頭の中では、CAからの証明書が提供されれば十分だと思いました。
彼らが探していた答えはデジタル署名でした。私は完全に忘れていました。それにもかかわらず、その後、私は完全な頭痛のように感じ、私の知識にいくつかの穴を埋めることに決め、いくつかのことを学びました。
要約すると(何か不足している場合は、遠慮なく教えてください)デジタル署名は、証明書の一部のデータをハッシュし、CA秘密鍵を使用して暗号化することで作成されます。署名の生成に使用される証明書の同じデータでハッシュし、証明書の公開鍵を使用してデジタル署名を復号化し、ハッシュを取得して、それらを比較します。
ここで少し困惑しているのは、クライアントが証明書のどの部分をハッシュして、デジタル署名の証明書の公開キーを使用して取得したハッシュと比較するのかをクライアントにどのように伝えるかです。 x.509には標準がありますか、それとも証明書のすべてをハッシュしますか?または、ハッシュを生成する方法についてどういうわけか通信しますか?
...ハッシュする証明書の部分... x.509には標準がありますか、それとも証明書のすべてをハッシュしますか?
すべて RFC 528 で定義されています。 セクション4.1.1.3。 には次のものが含まれます。
4.1.1.3。 signatureValue
signatureValueフィールドにはデジタル署名が含まれていますASN.1 DERでエンコードされたtbsCertificateで計算。
そして、このtbsCertificateが何であるかを調べるには、セクション4.1.2を読み続けます。
4.1.2。 TBSCertificate
シーケンスTBSCertificateには、証明書のサブジェクトとそれを発行したCAに関連する情報が含まれています。すべてのTBSCertificateには、サブジェクトと発行者の名前、サブジェクトに関連付けられた公開鍵、有効期間、バージョン番号、シリアル番号が含まれています。オプションの一意の識別子フィールドが含まれている場合があります。
証明書自体は、tbsCertificate、signatureAlgorithm、および署名になります。または、より正式に定義された方法 116ページ :
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
...