Microsoft OCSP检查（OCSP与轻量级OCSP）并通过“certutil -url”混淆响应

Question

Regular OCSP (RFC 6960)

我编写了一个OCSP响应程序，响应基于RFC 6960，其中指出：

如果未设置nextUpdate，则响应者将指示较新的吊销信息始终可用。

所以我没有设置nextUpdate，只是像这里一样使用了Bouncy Castle qazxsw poi（默认设置此更新，如Wireshark Capture中所示）：

BasicOCSPRespBuilder

但是IIS中的证书身份验证器拒绝了这些响应。在尝试certutil时，响应状态始终为“已过期”。

basicOCSPRespBuilder.addResponse(certID, responseList.get(certID));

这是使用“certutil -url”命令验证的。

Lightweight OCSP (RFC 5019)

一些谷歌搜索透露，微软支持轻量级OCSP，根据声明：

客户端必须检查nextUpdate字段是否存在，并且必须确保当前时间（如第2.2.4节所述，以GMT时间表示）落在thisUpdate和nextUpdate时间之间。如果nextUpdate字段不存在，客户端必须拒绝响应。

所以我修改了实现以包含nextUpdate Date（将来几分钟），如下所示：

RFC 5019

这让我摆脱了“过期”状态问题，但现在的问题是当它部署到Web服务器并且我尝试执行“certutil -url”检查时，它会在证书中返回“已验证”的WebProxy链接，但如果我直接提供服务器的URL，它会显示“OK”。响应结构在两种情况下保持相同，因为它是相同的响应者（使用Wireshark Capture验证，如果您愿意，我也可以附加它）。

basicOCSPRespBuilder.addResponse(certID, responseList.get(certID), getNextUpdateDate(), null);

issuerKeyHash field

这里有趣的事实是，在通过WebProxy和Direct URL的情况下，发送到服务器的OCSP请求是不同的。在向直接链路发送请求时，OCSP请求的不同之处不包括。

Wireshark捕获发送到Webproxy的OCSP请求，返回“已验证”： -

issuerKeyHash

Wireshark捕获的OCSP请求发送到返回状态为“OK”的直接链接： -

问题是请求如何在一个实例中包含issuerKeyHash而在另一个实例中不包括。此外，为什么两个查询的状态不同，即使来自服务器的OCSP响应类似（由Wireshark Caputres确认）。

对于“URL检索工具”或“certutil -verify”这方面的任何富有洞察力的文档/链接，我也将不胜感激。

我还可以根据要求提供Wireshark Captures。

我没有将Java和Bouncycastle作为标签包括在内，因为OCSP响应被Java，openssl等接受而没有任何问题（根据RFC 6960有或没有nextUpdate）。本课题旨在了解Microsoft certutil和OCSP检查的内容。

Update #1

---开始更新＃1 ---

正如@ Crypt32所建议的那样;我可以验证在URL字段中使用URL时，不会因未知原因构建完整的证书路径，因此缺少。

假设响应始终包含IssuerKeyHash，这可能导致“OK”而不是“Verified”状态。为了确认这一点，我修改了响应以匹配请求，如果请求中没有发送IssuerKeyHash，则状态仍为“OK”且未更改为“Verified”。

我们的想法是正确理解Microsoft Applications如何处理OCSP响应以及如何正确实现Responder，以免Microsoft应用程序出现问题。

研究正在进行中，任何建议和建

---结束更新＃1 ---

Answer 1

Re. nextUpdate

Microsoft使用轻量级OCSP，因此需要IssuerKeyHash和thisUpdate作为nextUpdate中引用的强制性要求。

Re. certutil

由于@ Crypt32，关于RFC 5019的查询现已得到澄清。

Re. IssuerKeyHash

在certutil的“URL to download”框中使用自定义URL时，不会生成完整的证书链，从而导致没有certutil的OCSP请求。

标准的CryptoAPI客户端永远不会发送带有空IssuerKeyHash的OCSP请求，这只是奇怪的IssuerKeyHash行为，可能会被忽略，因为它也会因Windows OCSP服务器而失败（在我的同时也通过Microsoft CA验证）