在对等验证期间发送的两个证书。为什么？答案

【问题标题】：two certificates sent during peer verification. Why?在对等验证期间发送的两个证书。为什么？
【发布时间】：2011-04-27 04:10:23
【问题描述】：

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')

如何在客户端和服务器端都获得两个证书。一种没有 CommonName，另一种具有正确的 CommonName= myownserver.com/myownclient.com

上述所有文件都只有一个密钥/证书。另外，我猜第一个打印的证书是 ca.crt，因为它是唯一没有任何 CommonName 的证书。但是为什么会这样呢？

【问题讨论】：

标签： network-programming pyopenssl

【解决方案1】：

接受的答案并不完全提供信息，但足够接近以至于模糊相关..

首先，set_verify 中verify_cb 的值是一个错字，因为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 发生的事情的解释可以在这里查看； Can someone explain this callback function for SSL certificates?

作为调试提示，您可以查看证书

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

回答直接问题：

a) 服务器收到客户端证书，因为它是客户端提供给服务器的

b) 服务器已经有一个根存储；受信任的根 CA 证书。您在连接的服务器上下文中看到的第二个证书将是与客户端证书颁发者 CA 匹配的根 CA 证书（如果 CA 在证书存储中）

c) 客户端上下文将拥有所有对等证书，而不仅仅是 2 个。通常一个服务器链是 3 个或更多；

根 CA - 在客户端设备根存储中）
singing CA 证书 - 您在为您的服务器购买证书时支付的公司，此 CA 在链中有一个证书，代表受信任的根 CA 授予他们的权限，因此他们可以为像您这样的客户签署证书
服务器证书 - 您购买并安装在网络服务器配置中的证书

d）在您的客户端上下文中有 2 个证书的事实向我表明您很有可能是自签名的。这意味着中间机构不是 CA，也不太可能被根 CA 信任，但您还是为您的服务器签署了证书：

intermediate 是用于签署服务器证书的自签名根证书。它没有受信任的根 CA，因此客户端上下文不会从您的信任存储中提取一个来完成典型的 3 链，从而导致您的链中只有 2 个证书
自签名的服务器证书

e) 由于问题表明 tls 协商成功，并且服务器上下文中有 2 个证书，这表明自签名证书已添加到您的服务器受信任的根存储中。这可能在许多方法中发生，但使用问题特定库 pyOpenSSL 的运行时方法将是 ctx.load_verify_locations(cafile)，因为自签名证书最有可能添加到服务器上的受信任根存储中

【讨论】：

【解决方案2】：

这取决于为验证设置的depth。

来自手册页当前上下文允许的证书链验证的最大深度。另外，depth 的默认值是9。

【讨论】：