#Regular OCSP (RFC 6960) 我写了一个 OCSP 响应程序，其中响应基于RFC 6960，它声明：
如果未设置 nextUpdate，则响应者指示更新的撤销信息始终可用。
所以我没有设置 nextUpdate 而是BasicOCSPRespBuilder像这里一样使用 BouncyCastle （默认设置 thisUpdate，在 Wireshark Capture 中也可以看到）：
basicOCSPRespBuilder.addResponse(certID, responseList.get(certID));
但是这些响应被 IIS 中的证书身份验证器拒绝。在尝试 certutil 时，响应状态始终为“已过期”。
这是使用“certutil -url”命令验证的。
#Lightweight OCSP (RFC 5019) 一些谷歌搜索显示，微软根据RFC 5019支持 Lightweight OCSP，其中指出：
客户端必须检查 nextUpdate 字段是否存在，并且必须确保当前时间（如第 2.2.4 节所述，以 GMT 时间表示）位于 thisUpdate 和 nextUpdate 时间之间。如果 nextUpdate 字段不存在，客户端必须拒绝响应。
所以我修改了实现以包含一个 nextUpdate 日期（未来几分钟），如下所示：
basicOCSPRespBuilder.addResponse(certID, responseList.get(certID), getNextUpdateDate(), null);
这让我摆脱了“过期”状态问题，但现在的问题是，当它被部署到 Web 服务器并且我尝试执行“certutil -url”检查时，它为证书中的 WebProxy 链接返回“已验证”，但如果我直接提供服务器的 URL，它会显示“OK”。Response 结构在两种情况下都保持不变，因为它是同一个响应者（使用 Wireshark Capture 进行了验证，如果您愿意，我也可以附上它）。
#issuerKeyHash 字段 这里有趣的事实是，通过 WebProxy 和 Direct URL 发送到服务器的 OCSP 请求是不同的。不同之处在于 OCSP 请求不包括将issuerKeyHash请求发送到直接链接时。
Wireshark 捕获发送到 Webproxy 并返回“已验证”的 OCSP 请求：-
发送到返回状态“OK”的直接链接的 OCSP 请求的 Wireshark 捕获：-
问题是请求如何在一个实例中包含 issuerKeyHash 而在另一个实例中不包含。此外，即使来自服务器的 OCSP 响应相似（由 Wireshark Caputres 确认），为什么两个查询的状态也不相同。
在这方面，我还将感谢“URL 检索工具”或“certutil -verify”的任何有见地的文档/链接。
我还可以根据要求包含 Wireshark Captures。
我没有将 Java 和 Bouncycastle 作为标签包括在内，因为 Java、openssl 等都接受了 OCSP 响应，没有任何问题（根据 RFC 6960 有或没有 nextUpdate）。这个问题是为了了解 Microsoft certutil & OCSP Check here 发生了什么。
#Update #1 --- 开始更新 #1 ---
正如@Crypt32 所建议的那样；我可以验证当在 URL 字段中使用 URL 时，由于未知原因没有构建完整的证书路径，因此缺少IssuerKeyHash.
假设是响应始终包含IssuerKeyHash，这可能导致“OK”而不是“Verified”状态。为了确认这一点，我修改了响应以匹配请求并且没有发送IssuerKeyHash如果它没有在请求中交付但状态保持“正常”并且没有更改为“已验证”。
我们的想法是正确理解 Microsoft 应用程序如何处理 OCSP 响应以及如何正确实施响应程序，以使 Microsoft 应用程序不会一蹶不振。
研究正在进行中，任何建议和建议表示赞赏！
--- 结束更新 #1 ---
