Skip to main content
Verify that the OCSP responder signs responses using the CryptoHub HSM end to end.
The following verification steps can be performed from either a Linux or Windows client.

​
Prerequisites

Before running the verification steps, ensure the following:
  • The client machine can reach the OCSP server on port 80.
  • An end-entity certificate issued by your CA is available on the client machine. It must have been issued after the OCSP URL was added to the CA’s AIA extension.
  • The CA certificate is available on the client machine.
Do not use the CA certificate itself for OCSP verification. The CA certificate does not contain an OCSP URL. You must use an end-entity certificate issued by the CA.
If you need an example of how to issue a test certificate, open the section below.
Enterprise CA. The example below uses a template named Test-Cert. Create it first by duplicating the Web Server template in certtmpl.msc: on the Subject Name tab select Supply in the request, on the Security tab grant Authenticated Users Read and Enroll, then publish it via certsrv.msc > Certificate Templates > New > Certificate Template to Issue.
On the machine where you want the test certificate, create the request INF and submit it.
The test certificate’s key type is independent of the OCSP signing key’s key type. The OCSP responder can sign a response for an RSA leaf using an ECDSA signing key, and vice versa. That said, to exercise the ECC path fully it is reasonable to issue an ECC test leaf. To do so, replace KeyLength = 2048 with KeyAlgorithm = ECDSA_P384 and KeyLength = 384 (and HashAlgorithm = SHA384) in the INF below. Leaving it RSA is also fine — what is being verified is the responder’s signature, not the leaf’s key type.
Standalone CA — find your CA configuration string on the CA server:
Then create and submit the request (replace <CA-Server-FQDN>\<CAName> with your CA configuration string):
Enterprise CA — reference the published template in the INF and submit directly. Because Test-Cert uses “Supply in the request”, this can be submitted as the logged-in user:
The submit output should end with Certificate retrieved(Issued) Issued.
The repeated word is expected — (Issued) is the status code returned by certreq and Issued is the CA’s disposition string.
If it shows CMC_STATUS_PENDING (Standalone CA with manual approval), issue the request on the CA via certsrv.msc > Pending Requests > All Tasks > Issue, then retrieve it:
Copy C:\test_cert.cer to the client machine before proceeding with verification.
Installing the test certificate with certreq -accept may fail with CRYPT_E_NOT_FOUND if the request was generated in a different context than where you are accepting it. For verification purposes you do not need to accept it — installing the public certificate with certutil -addstore My C:\test_cert.cer is sufficient.

​
Option A: Verify from Linux

1
Verify openssl is installed:
If not installed, run:
The output should show the OpenSSL version, for example OpenSSL 3.0.2 15 Mar 2022.
2
Obtain the CA certificate. For an Enterprise CA it can be downloaded directly from the CA server’s CertEnroll over HTTP:
Bash
Otherwise, copy the .crt from the CA server by your preferred method.
3
The CA certificate from a Windows CA is in DER format. Convert it to PEM:
Bash
Confirm the subject and issuer look correct (for a root CA they are identical):
4
Convert the test certificate to PEM if necessary. First check the file format:
Bash
  • If the output shows PEM certificate, copy it as-is:
  • If the output shows data or DER, convert it:
5
Verify the certificate contains the OCSP URL in its AIA extension:
Bash
The output should show the OCSP URL pointing to your OCSP server:OCSP - URI:http://<OCSP-server-IP>/ocspIf no OCSP URL is shown, the certificate was issued before the AIA extension was configured. Issue a new certificate and repeat this step.
6
Send an OCSP query to the OCSP server:
Bash
Replace <OCSP-server-IP> with the IP address or hostname of your OCSP server.
The output should confirm a successful OCSP response:
The key fields to verify are:
  • OCSP Response Status: successful (0x0)
  • Cert Status: good
  • Response verify OK — confirms the response was signed correctly by the CryptoHub HSM
7
On the OCSP server, verify that IIS handled the OCSP request by checking the IIS logs:
Command Prompt
Replace <YYMMDD> with today’s date, for example u_ex260603.log for June 3, 2026.
Locate the entry matching the timestamp of your OCSP query and confirm:POST /ocsp - 80 - <client-IP> - - 200 0 0
  • POST /ocsp — IIS received and routed the OCSP request.
  • 200 — IIS returned a successful response.
  • <client-IP> — matches the client machine that sent the query.
This confirms the full chain: the client reached the OCSP responder through IIS, which forwarded the request to the Online Responder, which signed the response using the CryptoHub HSM.

​
Option B: Verify from Windows

1
Obtain the CA certificate. For an Enterprise CA it can be downloaded directly from the CA server’s CertEnroll over HTTP:
Otherwise, copy the .crt from the CA server by your preferred method.
2
Import the CA certificate into the Trusted Root Certification Authorities store:
The output should confirm the certificate was added:
3
Verify the test certificate contains the OCSP URL in its AIA extension:
The output should show the OCSP URL pointing to your OCSP server:URL=http://<OCSP-server-IP>/ocspIf no OCSP URL is shown, the certificate was issued before the AIA extension was configured. Issue a new certificate and repeat this step.
4
Run the end-to-end verification:
The output should include:
The key fields to verify are:
  • Verified “OCSP” — the OCSP response was retrieved and verified from your OCSP server.
  • Leaf certificate revocation check passed — the revocation check passed end-to-end.
  • CertUtil: -verify command completed successfully — the full chain and revocation check succeeded.
Expected, ignorable errors in the output:
  • ldap:///... AIA and CDP errors (ERROR_LOGON_FAILURE) — the AD-integrated LDAP paths require domain credentials in the verifying context and may fail when running the command in a non-domain context. The HTTP OCSP and CRL checks are what matter.
  • file:// AIA/CDP errors — local UNC paths that only resolve on the CA server itself.
Not ignorable once you intend to rely on delta CRLs: a 404 on the delta CRL (<CAName>+.crl) means the CRL-hosting IIS site has not had double-escaping enabled. If you only see the base CRL verified and the delta 404s, apply the allowDoubleEscaping fix in Serve the CRL via IIS. OCSP verification can still pass on the base CRL alone, so this will not fail this check — but it should be fixed for a complete configuration.As long as the HTTP Verified "OCSP" and Verified "Base CRL" lines appear and the final result is Leaf certificate revocation check passed, the integration is working.