Skip to main content
Verify that the OCSP responder signs responses using the CryptoHub HSM end to end.
The following steps can be performed from either a Linux or Windows client. Both verify the same thing — that the OCSP responder is correctly signing responses using the CryptoHub HSM.

​
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:
certutil -dump | findstr "Config:"
Then create and submit the request (replace <ServerName>\<CAName> with your CA configuration string):
@"
[Version]
Signature="`$Windows NT`$"

[NewRequest]
Subject = "CN=OCSP Test Certificate"
KeyLength = 2048
HashAlgorithm = SHA256
MachineKeySet = FALSE
RequestType = PKCS10

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1
"@ | Out-File -FilePath C:\test_request.inf -Encoding ASCII

certreq -new C:\test_request.inf C:\test_request.req
certreq -submit -config "<ServerName>\<CAName>" C:\test_request.req C:\test_cert.cer
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:
@"
[Version]
Signature="`$Windows NT`$"

[NewRequest]
Subject = "CN=TestCert.<your-domain>"
KeyAlgorithm = RSA
KeyLength = 2048
HashAlgorithm = SHA256
MachineKeySet = TRUE
Exportable = FALSE
RequestType = CMC

[RequestAttributes]
CertificateTemplate = Test-Cert
"@ | Out-File -FilePath C:\test_request.inf -Encoding ASCII

certreq -new C:\test_request.inf C:\test_request.req
certreq -submit -config "<CA-Server-FQDN>\<CAName>" C:\test_request.req C:\test_cert.cer
The submit output should end with Certificate retrieved(Issued) Issued. 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:
certreq -retrieve -config "<ServerName>\<CAName>" <RequestID> C:\test_cert.cer
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:
openssl version
If not installed, run:
sudo apt install openssl -y
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
curl -o futurex-ca.crt http://<CA-server-IP>/CertEnroll/<ServerHostname>_<CAName>.crt
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
openssl x509 -inform DER -in futurex-ca.crt -out futurex-ca.pem
Confirm the subject and issuer look correct (for a root CA they are identical):
openssl x509 -in futurex-ca.pem -noout -subject -issuer
4
Convert the test certificate to PEM if necessary. First check the file format:
Bash
file test_cert.cer
  • If the output shows PEM certificate, copy it as-is: 
    cp test_cert.cer test_cert.pem
  • If the output shows data or DER, convert it: 
    openssl x509 -inform DER -in test_cert.cer -out test_cert.pem
5
Verify the certificate contains the OCSP URL in its AIA extension:
Bash
openssl x509 -in test_cert.pem -noout -text | grep -A2 "OCSP"
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
openssl ocsp \
  -issuer futurex-ca.pem \
  -cert test_cert.pem \
  -url http://<OCSP-server-IP>/ocsp \
  -CAfile futurex-ca.pem \
  -no_nonce \
  -resp_text
Replace <OCSP-server-IP> with the IP address or hostname of your OCSP server.
The output should confirm a successful OCSP response:
Response verify OK
test_cert.pem: good
    This Update: <date>
    Next Update: <date>
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
type C:\inetpub\logs\LogFiles\W3SVC1\u_ex<YYMMDD>.log
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
Import the CA certificate into the Trusted Root Certification Authorities store:
certutil -addstore Root "C:\<ServerHostname>_<CAName>.crt"
Use the actual CA certificate filename from your environment.
The output should confirm the certificate was added:
CertUtil: -addstore command completed successfully.
2
Verify the test certificate contains the OCSP URL in its AIA extension:
certutil -dump "C:\test_cert.cer" | findstr /i "ocsp"
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.
3
Run the end-to-end verification:
certutil -verify -urlfetch "C:\test_cert.cer"
The output should include:
Verified "OCSP" Time: 0
[0.0] http://<OCSP-server-IP>/ocsp
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.
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.

​
Clean up

The following commands are destructive and are intended only for tearing down a test deployment. Do not run them against a production CA or OCSP server.
  • Remove CA configuration 
    Uninstall-AdcsCertificationAuthority -Force
  • Clean up old certs 
    certutil -delstore My "<CertSubjectOrSerial>"