Microsoft OCSP Check (OCSP vs Lightweight OCSP) & confusing Responses by "certutil -url"

Question

#Regular OCSP (RFC 6960) I have written an OCSP Responder where the Response based itself on the RFC 6960 which states that :

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

So I did not set the nextUpdate and just used the BouncyCastle BasicOCSPRespBuilder like here (which sets thisUpdate by default,as also seen in Wireshark Capture) :

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

But these responses were rejected by the certificate authenticator in IIS. On trying certutil the response Status was always "Expired".

This was verified using "certutil -url " command.

#Lightweight OCSP (RFC 5019) A bit of googling revealed that Microsoft supports Lightweight OCSP as per RFC 5019 which states:

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

So I modified the implementation to include a nextUpdate Date ( a few minutes in future ), as below :

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

This got me out of the "Expired" Status problem, but now the issue is that when this is deployed to the Webserver and I attempt to perform the "certutil -url" check, it returns "Verified" for WebProxy link in the Certificate, but if I provide the URL of the server directly it displays an "OK". The Response structure remaining the same in both cases as it is the same responder ( Verified using the Wireshark Capture, I could attach this as well if you like ).

#issuerKeyHash field The interesting fact here is that the OCSP Requests sent to the server are different in case of via WebProxy and Direct URL. The difference being the OCSP Request does not include the issuerKeyHash when sending the request to the direct link.

Wireshark capture of OCSP Request sent to Webproxy that returned a "Verified" :-

Wireshark Capture of OCSP Request sent to direct link that returned status "OK" :-

The question is how come the request includes the issuerKeyHash in one and in the other instance not. Furthermore, why is the the Status not same for both the queries even though the OCSP Response from the Server is similar (confirmed by Wireshark Caputres).

I would also be grateful for any insightful documentation / link for the "URL Retrieval Tool" or "certutil -verify" in this regard.

I can also include the Wireshark Captures on request.

I haven't included Java and Bouncycastle as a tags as the OCSP Responses are accepted by Java, openssl etc. without any issues (with or without nextUpdate as per RFC 6960). This Question is to understand what's going on with Microsoft certutil & the OCSP Check here.

#Update #1 --- Begin Update #1 ---

As suggested by @Crypt32; I could verify that when using a URL in the URL Field, a complete Certificate-Path is not built for reasons unknown and hence the missing IssuerKeyHash.

The assumption was that the Response always contains IssuerKeyHash and this could be leading to the "OK" instead of "Verified" status. To confirm this I modified the response to match the request and did not send an IssuerKeyHash if it was not delivered in the Request but the status remained "OK" and didn't change to "Verified".

The idea is to correctly understand how Microsoft Applications process OCSP Responses and how to implement the Responder correctly so that no Microsoft Applications fall flat on their face.

Research ongoing, any advise and suggestions appreciated !!

--- End Update #1 ---

From what I understand, when you use OCSP URL in certificate (URL textbox is empty and radiobutton is on OCSP), certutil performs certificate chain building and can get issuer certificate and get `issuerKeyHash`. When you provide explicit URL in certutil, it doesn't build certification path, thus `issuerKeyHash` is empty. `Verified` status means that the tool got valid OCSP response and the certificate status is `good`. `OK` status means that OCSP responded with non-fault response, but there is no enough information to validate the status. — Crypt32, Feb 19 '18 at 06:23
Thanks for the insight. But about the "OK" Status, the response is exactly the same as the one when we get the "Verified", why would there not be enough information to verify the response then ? — Exception_al, Feb 19 '18 at 07:42
Responses are (most likely) are not the same to requests, because `CertID` structures doesn't match (request is missing `issuerKeyHash` and is included in response. Right?). This issue cannot be solved here easily. I would suggest to contact me directly (you can find contact details in profile page) and if we find the answer, it will be published in this thread. — Crypt32, Feb 19 '18 at 12:52
Actually, your behavior is ok now, because CryptoAPI client will never send request with empty `issuerKeyHash` field. At this point you are struggling with specific certutil behavior, which isn't a business requirement. Certutil fails against Windows OCSP servers as well. — Crypt32, Feb 21 '18 at 18:56
Anyone knows if the source code for `certutil.exe` is available at least for reference and debug?. It is so frustrating to not have a direct place to search answers for the misleading behavior of this tool. — Jaime Hablutzel, Oct 19 '18 at 23:57

score 3 · Accepted Answer · edited Oct 07 '21 at 10:53

Re. nextUpdate

Microsoft uses the Lightweight OCSP and hence requires a thisUpdate and nextUpdate as mandatory as cited in the RFC 5019.

Re. certutil

The query regarding certutil has now been clarified thanks to @Crypt32.

Re. IssuerKeyHash

When using a custom URL in the "URL to download" box of certutil, a complete certificate chain is not generated and hence resulting in an OCSP Request without IssuerKeyHash.

Standard CryptoAPI clients never send an OCSP Request with empty IssuerKeyHash and this is just peculiar certutil behavior which may be ignored as it also tends to fail with Windows OCSP Servers (verified at my end with a Microsoft CA as well)

StackzOfZtuff · Answer 2 · 2021-02-04T08:20:28.983

Details for "certutil -url"

Partial answer only.

"CertUtil" is a general Microsoft certificate/PKI tool. It can do a LOT of things.

Now this URL Retrieval Tool GUI is what happens when you start it with the "-url" parameter.

What I find a little strange is that the -URL parameter is NOT publicly documented.

It's not listed on Microsoft.com documentation: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil
It's not even listed on ss64: https://ss64.com/nt/certutil.html

It's not listed in the "CertUtil -v -? -- Display all help text for all verbs" included help. There's only -URLCache and -urlfetch but not -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

But it DOES have some help text, if you ask for it specifically:

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

To get the "URL Retrieval Tool" GUI to come up, you can just start certutil like this.

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

Microsoft OCSP Check (OCSP vs Lightweight OCSP) & confusing Responses by "certutil -url"

2 Answers2

Re. nextUpdate

Re. certutil

Re. IssuerKeyHash

Details for "certutil -url"