windows - Microsoft OCSP 检查(OCSP 与轻量级 OCSP)和 "certutil -url"令人困惑的响应

Question

#常规 OCSP (RFC 6960)我编写了一个 OCSP 响应程序，其中响应基于 RFC 6960其中指出:

If nextUpdate is not set, the responder is indicating that newerrevocation information is available all the time.

所以我没有设置 nextUpdate，只是像这里一样使用了 BouncyCaSTLe BasicOCSPRespBuilder(它默认设置了 thisUpdate，在 Wireshark Capture 中也可以看到):

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

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

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

#轻量级 OCSP(RFC 5019)一些谷歌搜索显示微软支持轻量级 OCSP，根据 RFC 5019其中指出:

Clients MUST check for the existence of the nextUpdate field and MUSTensure the current time, expressed in GMT time as described inSection 2.2.4, falls between the thisUpdate and nextUpdate times. Ifthe nextUpdate field is absent, the client MUST reject the response.

所以我修改了实现以包含 nextUpdate 日期( future 几分钟)，如下所示:

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

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

#issuerKeyHash 字段这里有趣的事实是，在通过 WebProxy 和直接 URL 的情况下，发送到服务器的 OCSP 请求是不同的。区别在于 OCSP 请求在将请求发送到直接链接时不包括 issuerKeyHash。

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

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

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

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

我还可以根据要求包含 Wireshark 捕获。

我没有将 Java 和 BouncycaSTLe 作为标记包含在内，因为 OCSP 响应被 Java、openssl 等接受，没有任何问题(根据 RFC 6960，有或没有 nextUpdate)。这个问题是为了了解 Microsoft certutil 和此处的 OCSP 检查发生了什么。

#更新 #1--- 开始更新 #1 ---

如@Crypt32 所建议；我可以验证在 URL 字段中使用 URL 时，由于未知原因未构建完整的证书路径，因此缺少 IssuerKeyHash。

假设响应总是包含 IssuerKeyHash，这可能导致“OK”而不是“Verified”状态。为了确认这一点，我修改了响应以匹配请求，并且如果它未在请求中交付但状态保持“正常”并且没有更改为“已验证”，则不会发送 IssuerKeyHash。

我们的想法是正确理解 Microsoft 应用程序如何处理 OCSP 响应以及如何正确实现 Responder，以便 Microsoft 应用程序不会完全失败。

研究正在进行中，任何意见和建议表示赞赏!!

--- 结束更新 #1 ---

Answer 1

回复。下一次更新

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

回复。认证工具

关于 certutil 的查询现已得到澄清，感谢 @Crypt32。

回复。 IssuerKeyHash

在 certutil 的“下载 URL” 框中使用自定义 URL 时，不会生成完整的证书链，因此导致没有 的 OCSP 请求>IssuerKeyHash.

标准 CryptoAPI 客户端从不发送带有空 IssuerKeyHash 的 OCSP 请求，这只是特殊的 certutil 行为，可能会被忽略，因为它也往往会在 Windows OCSP 服务器上失败(我也通过 Microsoft CA 进行了验证)