0 
def cert_check(conn,cert,errnum,depth,ok):
    print 'Got cert',cert.get_subject()
    return ok

サーバ：

ctx = SSL.context(SSL.TLSv1_METHOD)
ctx.set_verify(SSL.VERIFY_PEER,verify_cb)
ctx.use_private_key_file('server.key')
ctx.use_certificate_file('server.crt')
ctx.load_verify_locations('ca.crt')

クライアント：

ctx = SSL.context(SSL.TLSv1_METHOD)
ctx.set_verify(SSL.VERIFY_PEER,verify_cb)
ctx.use_private_key_file('client.key')
ctx.use_certificate_file('client.crt')
ctx.load_verify_locations('ca.crt')

クライアント側とサーバー側の両方で、2 つの証明書を取得するのはどうしてですか。CommonName のないものと正しい CommonName= myownserver.com/myownclient.com を持つもの

前述のすべてのファイルには、キー/証明書が 1 つだけ含まれています。また、CommonName を持たない唯一の証明書であるため、最初に印刷された証明書は ca.crt であると推測しています。しかし、なぜそれが起こるのでしょうか？

4

2 に答える 2

0

受け入れられた回答は正確には有益ではありませんが、漠然と関連しているほど十分に近い..

まず第一に、verify_cbinの値はset_verifyタイプミスcert_checkであり、適切な関数シグネチャであるように思われるため、質問の修正は次のとおりです。

def cert_check(conn,cert,errnum,depth,ok):
    print 'Got cert',cert.get_subject()
    return ok

Server:

ctx = SSL.context(SSL.TLSv1_METHOD)
ctx.set_verify(SSL.VERIFY_PEER,cert_check)
ctx.use_private_key_file('server.key')
ctx.use_certificate_file('server.crt')
ctx.load_verify_locations('ca.crt')

Client:

ctx = SSL.context(SSL.TLSv1_METHOD)
ctx.set_verify(SSL.VERIFY_PEER,cert_check)
ctx.use_private_key_file('client.key')
ctx.use_certificate_file('client.crt')
ctx.load_verify_locations('ca.crt')

How is it that on both client and server side, I get two certificates. One with no CommonName and one with the correct CommonName= myownserver.com/myownclient.com

何が起こっているかの説明は、set_verifyここで確認できます。誰かが SSL 証明書のこのコールバック関数を説明できますか?

デバッグのヒントとして、証明書を表示できます

print(dump_certificate(FILETYPE_TEXT, cert).decode())

直接の質問に答えるには：

a) サーバーは、クライアントからサーバーに提供されたクライアント証明書を受け取りました。

b) サーバーにはすでにルート ストアがあります。信頼されたルート CA 証明書。接続のサーバー コンテキストに表示される 2 番目の証明書は、クライアント証明書の発行者 CA と一致するルート CA 証明書になります (CA が証明書ストアにある場合)。

c) クライアント コンテキストには、2 つだけでなく、すべてのピア証明書が含まれます。通常、サーバー チェーンは 3 つ以上です。

  • ルート CA - クライアント デバイスのルート ストア内)
  • 歌う CA 証明書 - サーバーの証明書を購入したときに支払った会社。この CA には、信頼されたルート CA によって与えられた権限を表す証明書がチェーン内にあるため、顧客のような顧客のために証明書に署名することができます。
  • server cert - 購入してウェブサーバー構成にインストールした証明書

d) クライアント コンテキストに 2 つの証明書があったという事実は、あなたが自己署名した可能性が高いことを示しています。これは、中間機関が CA ではなく、ルート CA によって信頼されていない可能性が高いことを意味しますが、とにかくサーバーの証明書に署名しました:

  • 中間は、サーバー証明書の署名に使用される自己署名ルート証明書です。信頼されたルート CA がないため、クライアント コンテキストは信頼ストアから 1 つを引き出して 3 つの典型的なチェーンを完成させず、チェーン内の証明書は 2 つだけになります。
  • 自己署名されたサーバー証明書

e) 質問は TLS ネゴシエーションが成功したこと、およびサーバー コンテキストに 2 つの証明書があったことを示しているため、これは自己署名証明書がサーバーの信頼されたルート ストアに追加されたことを示しています。pyOpenSSLこれは多くの方法で発生する可能性がありますが、質問固有のライブラリを使用するランタイム方法はctx.load_verify_locations(cafile)、自己署名証明書がサーバー上の信頼されたルート ストアに追加された可能性が最も高い場所です。

于 2021-10-05T23:16:49.640 に答える
-1

これは、depth検証用に設定されている によって異なります。

man ページから、現在のコンテキストで許可される証明書チェーン検証の最大深度。また、depthのデフォルト値は9です。

于 2011-05-06T19:17:51.353 に答える