常规OCSP(RFC 6960)
我已经编写了OCSP响应程序，其中响应本身基于RFC 6960，其中指出:
所以我没有设置nextUpdate，而是像这里一样使用BouncyCaSTLe BasicOCSPRespBuilder(默认情况下设置thisUpdate，在Wireshark Capture中也可以看到):
basicOCSPRespBuilder.addResponse(certID, responseList.get(certID));
但是这些响应被IIS中的证书身份验证器拒绝。尝试certutil时，响应状态始终为“过期”。
使用“certutil -url”命令对此进行了验证。
轻量级OCSP(RFC 5019)
稍作搜索后发现，按照RFC 5019，Microsoft支持轻量级OCSP，其中指出:
因此，我对实现进行了修改，以包含nextUpdate日期(将来几分钟)，如下所示:
basicOCSPRespBuilder.addResponse(certID, responseList.get(certID), getNextUpdateDate(), null);
这使我摆脱了“过期”状态问题，但是现在的问题是，当此问题部署到Web服务器并且我尝试执行“certutil -url”检查时，它为证书中的WebProxy链接返回“已验证”，但是如果我直接提供服务器的URL，它将显示“确定”。两种情况下，Response结构都保持不变，因为它是同一响应者(使用Wireshark Capture进行了验证，如果您愿意，我也可以附加此结构)。
issuerKeyHash字段
有趣的事实是，通过WebProxy和Direct URL发送到服务器的OCSP请求是不同的。将OCSP请求发送到直接链接时，不同之处在于OCSP请求不包括
issuerKeyHash。Wireshark捕获发送到Webproxy的OCSP请求，该请求返回“已验证”:-
Wireshark捕获的OCSP请求已发送到返回状态为“OK”的直接链接:-
问题是请求如何在一个实例中包含issuerKeyHash而在另一个实例中则不包含。此外，即使来自服务器的OCSP响应相似(由Wireshark Caputres确认)，两个查询的状态为何也不相同。
在此方面，对于“URL检索工具”或“certutil -verify”的任何有见地的文档/链接，我也将不胜感激。
我还可以应要求提供Wireshark Captures。
我没有将Java和BouncycaSTLe包含为标签，因为OCSP响应已被Java，openssl等接受，没有任何问题(根据RFC 6960是否具有nextUpdate)。该问题是为了了解Microsoft certutil和OCSP Check的操作。
更新＃1
-开始更新＃1-
如@ Crypt32所建议；我可以验证在URL字段中使用URL时，出于未知原因(因此缺少
IssuerKeyHash)，未构建完整的证书路径。假定响应始终包含
IssuerKeyHash，这可能导致状态为“OK”而不是“Verified”。为了确认这一点，我修改了响应以匹配请求，并且如果未在请求中传递IssuerKeyHash，但未发送ojit_code，但状态仍然为“OK”，并且未更改为“Verified”。这样做的目的是正确理解Microsoft应用程序如何处理OCSP响应以及如何正确实现响应程序，以使没有Microsoft应用程序浮出水面。
研究正在进行中，任何意见和建议表示赞赏!
-结束更新1-
最佳答案
回覆。 nextUpdate
Microsoft使用轻量级OCSP，因此需要按照RFC 5019中的要求强制使用thisUpdate和nextUpdate。
回覆。 certutil
感谢@ Crypt32，现在已经澄清了有关certutil的查询。
回覆。 IssuerKeyHash
在certutil的“要下载的URL”框中使用自定义URL时，不会生成完整的证书链，因此会导致没有IssuerKeyHash的OCSP请求。
标准CryptoAPI客户端绝不会发送带有空IssuerKeyHash的OCSP请求，而这只是奇怪的certutil行为，可能会被忽略，因为它在Windows OCSP服务器上也容易失败(在我的Microsoft CA上也进行了验证)
关于windows - Microsoft OCSP检查(OCSP与轻量级OCSP)和 “certutil -url”引起的困惑响应，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48823807/