Microsoft OCSP Check（OCSP vs Lightweight OCSP）＆amp;令人困惑的回应＃34; certutil -url＆＃34;

Question

常规OCSP（RFC 6960）

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

  

如果未设置nextUpdate，则响应者指示更新      撤销信息始终可用。

所以我没有设置nextUpdate，只是像这里一样使用了BouncyCastle BasicOCSPRespBuilder（默认设置thisUpdate，也见于Wireshark Capture）：

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

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

使用＆＃34; certutil -url＆＃34;验证了这一点。命令。

轻量级OCSP（RFC 5019）

一些谷歌搜索透露，微软支持轻量级OCSP，符合RFC 5019规定：

  

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

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

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

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

issuerKeyHash字段

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

Wireshark捕获发送到Webproxy的OCSP请求，该请求返回了＆＃34;已验证＆＃34; ： -

Wireshark捕获OCSP请求发送到返回状态的直接链接＆＃34; OK＆＃34; ： -

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

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

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

我还没有将Java和Bouncycastle作为标签包含在内，因为OCSP响应被Java，openssl等接受而没有任何问题（根据RFC 6960有或没有nextUpdate）。这个问题是要了解Microsoft certutil＆amp; amp; OCSP在这里查看。

更新＃1

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

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

假设响应始终包含IssuerKeyHash，这可能导致＆＃34; OK＆＃34;而不是＆＃34;已验证＆＃34;状态。为了确认这一点，我修改了响应以匹配请求，并且如果请求中没有发送IssuerKeyHash，则不会发送{{1}}，但状态仍然是＆＃34; OK＆＃34;并没有改为＆＃34;已验证＆＃34;。

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

研究正在进行中，任何建议和建议都值得赞赏!!

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

Answer 1

重新。下次更新

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

重新。的certutil

由于@ Crypt32，现在已经澄清了关于certutil的问题。

重新。 IssuerKeyHash

在＆＃34; URL中使用自定义网址下载certutil的＃34; 框时，不会生成完整的证书链，因此会导致OCSP请求IssuerKeyHash。

标准CryptoAPI客户端从不发送空IssuerKeyHash的OCSP请求，这只是奇怪的certutil行为，可能会被忽略，因为它也会因Windows OCSP服务器而失败（在我的Microsoft CA也是如此）

Answer 2

“certutil -url”的详细信息

仅部分回答。

“CertUtil”是一个通用的微软证书/PKI 工具。它可以做很多事情。

现在这个 URL Retrieval Tool GUI 就是当您使用“-url”参数启动它时会发生什么。

我觉得有点奇怪的是 -URL 参数没有公开记录。

• 它未在 Microsoft.com 文档中列出：https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certutil
• 它甚至没有在 ss64 上列出：https://ss64.com/nt/certutil.html
• 它未列在 “CertUtil -v -? -- 显示所有动词的所有帮助文本” 中包含的帮助中。只有 -URLCache 和 -urlfetch 但没有 -url：

  PS C:\> Get-Command certutil | select -expand fileversioninfo | fl filename, fileversion
  FileName    : C:\WINDOWS\system32\certutil.exe
  FileVersion : 10.0.19041.1 (WinBuild.160101.0800)
  
  PS C:\> certutil -v -? | select-string ' -url'
    -URLCache         -- Display or delete URL cache entries
    CertUtil [Options] -URLCache [URL | CRL | * [delete]]
    -urlfetch         -- Retrieve and verify AIA Certs and CDP CRLs
  

但它确实有一些帮助文本，如果你特别要求它：

C:\> certutil.exe -URL -?
Usage:
  CertUtil [Options] -URL InFile | URL
  Verify Certificate or CRL URLs

Options:
  -f                -- Force overwrite
  -Unicode          -- Write redirected output in Unicode
  -gmt              -- Display times as GMT
  -seconds          -- Display times with seconds and milliseconds
  -split            -- Split embedded ASN.1 elements, and save to files
  -v                -- Verbose operation
  -privatekey       -- Display password and private key data
  -pin PIN                  -- Smart Card PIN
  -sid WELL_KNOWN_SID_TYPE  -- Numeric SID
            22 -- Local System
            23 -- Local Service
            24 -- Network Service

CertUtil -?              -- Display a verb list (command list)
CertUtil -URL -?         -- Display help text for the "URL" verb
CertUtil -v -?           -- Display all help text for all verbs

要使“URL 检索工具”GUI 出现，您可以像这样启动 certutil。

C:\> certutil -url http://example.com