这是否调用“openssl s_client -connect”实际查询OCSP响应者服务器以确认证书的当前有效性？

Question

我很好奇，调用一行openssl命令行界面是否有能力执行完整的OCSP验证协议，例如，查询链中的所有OCSP应答方服务器以确认证书的当前有效性。

要看看这可能是这样，我指定的-CAfile选项为/dev/null，希望将避免任何缓存的证书来代替查找的使用：作为@pepo的答案解释，服务器证书链被发送在RFC 5246（在下文中更新更多细节）中指定的基本TLS1.2握手的一部分

# openssl s_client -CAfile /dev/null -connect www.equifaxsecurity2017.com:443 

这给了输出：

CONNECTED(00000003) 
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority 
verify return:1 
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA 
verify return:1 
depth=1 C = US, O = GeoTrust Inc., OU = Domain Validated SSL, CN = GeoTrust DV SSL CA - G3 
verify return:1 
depth=0 CN = www.equifaxsecurity2017.com 
verify return:1 
--- 
Certificate chain 
0 s:/CN=www.equifaxsecurity2017.com 
    i:/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3 
1 s:/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3 
    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 
    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 
--- 
Server certificate 
-----BEGIN CERTIFICATE----- 
<omitted> 
-----END CERTIFICATE----- 
subject=/CN=www.equifaxsecurity2017.com 
issuer=/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3 
--- 
No client certificate CA names sent 
.... 

看起来好像openssl已经发现，在链中的所有三个环节没有任何帮助从缓存文件，因此必须传达在互联网上与代理商（1）GeoTrust的DV SSL CA - G3，和（ 2）GeoTrust Global CA，建立连锁。那是对的吗？ 不！这是不正确的！

是否openssl也通过向三个OCSP响应者中的每一个发出适当的OCSP请求来验证链？我也知道openssl ocsp ...可以与证书上的手动文本操作一起使用，一次执行一个链接执行OSCP验证。但是，它看起来似乎是合理的，甚至更可取的openssl会被写入到执行全OCSP验证，这就是为什么我问）

UPDATE 2017年9月14日：

由于@pepo的回答“SSL服务器（如果配置正确）将发送证书链（根CA证书除外）“，我查了RFC 5246，发现第”7.4.2 Se rver证书”这解释了的内容‘的TLS1.2握手的服务器证书’部分：

这是证书的序列（链）。发件人的
证书必须在列表中排在第一位。每个以下证书 必须直接证明前面的证书。由于证书 验证要求根密钥是独立分发的，因此可以从链中省略指定根证书 权限的自签名证书，前提条件是远程端必须已经拥有它才能验证它 任何情况。

此外，由于@西葫芦的有关-crl_check_all选项答案，我想这一点，得到了以下的输出：

CONNECTED(00000003) 
depth=0 CN = www.equifaxsecurity2017.com 
verify error:num=3:unable to get certificate CRL 
verify return:1 
depth=1 C = US, O = GeoTrust Inc., OU = Domain Validated SSL, CN = GeoTrust DV SSL CA - G3 
verify error:num=3:unable to get certificate CRL 

它失败，错误unable to get certificate CRL。事实证明，这并不重要，因为所选网站已启用OCSP装订。

如果不是-crl_check_all执行CRL检查，我们反而 add the option -status 它要求OCSP装订，那么下面的输出被接收：

CONNECTED(00000003) 
<stuff omitted omitted> 
OCSP response: 
====================================== 
OCSP Response Data: 
    OCSP Response Status: successful (0x0) 
    Response Type: Basic OCSP Response 
    Version: 1 (0x0) 
    Responder Id: CE2C8B1E8BD2300FD1B15446E9B594254949321B 
    Produced At: Sep 10 11:12:45 2017 GMT 
    Responses: 
    Certificate ID: ... 
    Cert Status: good 
    This Update: Sep 10 11:12:45 2017 GMT 
    Next Update: Sep 17 11:12:45 2017 GMT 
    Signature Algorithm: sha1WithRSAEncryption 
<stuff omitted> 

这表明OCSP装订在服务器上启用但是它似乎只对第一个（叶子）证书启用，而不是对第二个证书启用。 （无论如何，自签名的第三份证书必须独立验证）。因此，要验证第二个证书，必须使用CRL检查或必须使用OCSP请求响应。由于CRL检查未由此特定授权链启用，仅留下OCSP请求响应。

由于@pepo的答复，我明白好得多openssl之间的TLS1.2协议并且这些方法用于验证授权的关系，（在历史顺序列出）：

• CRL（证书撤销列表）检查
• OSCP请求和响应
• OCSP装订

然而，一个新的问题也被提出：

• 关于OCSP-装订的“服务器证书”消息步骤中通过与链中的证书一起服务器发送响应 - 这有签名信息（从下级别）需要验证。这个签名信息是否在openssl ... -status的处理过程中被实际验证过？

更新：2017年9月15日

的安全问题的答案“？是的openssl ... -status加工过程中实际验证了这个签名信息”似乎是NO，根据本 answer 也@ dave_thompson_085的评论如下（他浏览了源代码）。

它是否令人困惑？是!奇怪的是， “OpenSSL食谱（feistyduck，IvanRistić）” 是 unusually unclear about this question, 显示没有明确的方式来验证签名，同时也没有明确说明签名是否已被验证。与此相反，对于其他类型吊销检查的：

• CRL-checking
• and OCSP-request-response (find "submit OCSP request")

的“OpenSSL的食谱”显示了明确的方法（配方）去额外的距离和手动完成验证使用已由openssl产生的信息。推断原因“OpenSSL Cookbok”不包含完整验证订阅OCSP响应的原因是因为它不是必需的，这将是一个非常人为的错误。

恕我直言，这将是非常负责任的OpenSSL（或任何类似的库）的，包括顶层文件，在下列优先顺序

• （1）解释，即OpenSSL的不提供黑箱解决方案到TLS +授权，
• （2）解释什么限制了溶液它确实提供（例如，未经授权的TLS握手检查）的一部分，
• （3）上用于组装OpenSSL的组分配方文档来完成 授权检查方案。

误区传播变得非常容易。就在几天前，我试图编写一个简单的程序来从我的Linux Ubuntu PC发送通知邮件。标准的Python版本（包括版本2和版本3）包括一个SMTP和一个SSL库“实施”TLS1.2。在10分钟内，我可以编写程序并在调试器中遍历它。我可以看到python SSL库对OpenSSL的handshake()函数的调用，并假定handshake()必须处理所有的授权检查，这是基于假设在不包括授权检查的情况下不会发布SSL库和SMTP库。奇怪的是，SSL库中的调用代码包含post-handshake()检查以确保接收到的证书名称与被调用服务器的名称相匹配。 “如果handshake()已经处理了所有的签名验证等，为什么还要进行这样的原始检查呢？”我想。这种怀疑开始了剥离TLS安全洋葱层次的旅程，我从此无法停止哭泣。

我不想尝试重新发明轮子，这很可能是不稳定反正。但是，我似乎无法找到任何可用的轮子。然后去哪儿？

Answer 1

SSL服务器（如果配置正确地）将发送证书链（除了根CA证书）。你可以验证它here。

Openssl没有获取这些证书，但它在启动ssl连接时获得了它们的服务。你可以阅读更多有关的s_client.First行为openssl documentation

我不知道它是否执行OCSP验证，但我对此表示怀疑。恕我直言（基于The s_client utility is a test tool and is designed to continue the handshake after any certificate verification errors.），它完全不执行任何默认验证，但至少可以使CRL通过指定参数-crl_check_all

openssl s_client -connect www.equifaxsecurity2017.com:443 -crl_check_all