> ## Documentation Index > Fetch the complete documentation index at: https://docs.futurex.com/llms.txt > Use this file to discover all available pages before exploring further. # Verify the integration > Verify the end-to-end OCSP integration from a Linux or Windows client, confirming the Online Responder signs responses using the CryptoHub HSM. 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: ```powershell theme={null} certutil -dump | findstr "Config:" ``` Then create and submit the request (replace `\` with your CA configuration string): ```powershell theme={null} @" [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 "\" 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: ```powershell theme={null} @" [Version] Signature="`$Windows NT`$" [NewRequest] Subject = "CN=TestCert." 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 "\" C:\test_request.req C:\test_cert.cer ``` 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: ```powershell theme={null} certreq -retrieve -config "\" 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 Verify `openssl` is installed: ```bash theme={null} openssl version ``` If not installed, run: ```bash theme={null} sudo apt install openssl -y ``` The output should show the OpenSSL version, for example `OpenSSL 3.0.2 15 Mar 2022`. Obtain the CA certificate. For an Enterprise CA it can be downloaded directly from the CA server's CertEnroll over HTTP: ```bash expandable lines wrap title="Bash" theme={null} theme={null} curl -o futurex-ca.crt http:///CertEnroll/_.crt ``` Otherwise, copy the `.crt` from the CA server by your preferred method. The CA certificate from a Windows CA is in DER format. Convert it to PEM: ```bash expandable lines wrap title="Bash" theme={null} theme={null} 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): ```bash theme={null} openssl x509 -in futurex-ca.pem -noout -subject -issuer ``` Convert the test certificate to PEM if necessary. First check the file format: ```bash expandable lines wrap title="Bash" theme={null} theme={null} file test_cert.cer ``` * If the output shows `PEM certificate`, copy it as-is: ```bash theme={null} cp test_cert.cer test_cert.pem ``` * If the output shows `data` or `DER`, convert it: ```bash theme={null} openssl x509 -inform DER -in test_cert.cer -out test_cert.pem ``` Verify the certificate contains the OCSP URL in its AIA extension: ```bash expandable lines wrap title="Bash" theme={null} theme={null} 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` If no OCSP URL is shown, the certificate was issued before the AIA extension was configured. Issue a new certificate and repeat this step. Send an OCSP query to the OCSP server: ```bash expandable lines wrap title="Bash" theme={null} theme={null} openssl ocsp \ -issuer futurex-ca.pem \ -cert test_cert.pem \ -url http:///ocsp \ -CAfile futurex-ca.pem \ -no_nonce \ -resp_text ``` Replace `` with the IP address or hostname of your OCSP server. The output should confirm a successful OCSP response: ```Text theme={null} Response verify OK test_cert.pem: good This Update: Next Update: ``` 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 On the OCSP server, verify that IIS handled the OCSP request by checking the IIS logs: ```powershell expandable lines wrap title="Command Prompt" theme={null} theme={null} type C:\inetpub\logs\LogFiles\W3SVC1\u_ex.log ``` Replace `` 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 - - - 200 0 0` * **POST /ocsp** — IIS received and routed the OCSP request. * **200** — IIS returned a successful response. * **``** — 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 Obtain the CA certificate. For an Enterprise CA it can be downloaded directly from the CA server's CertEnroll over HTTP: ```powershell theme={null} Invoke-WebRequest -Uri "http:///CertEnroll/_.crt" -OutFile "C:\_.crt" -UseBasicParsing ``` Otherwise, copy the `.crt` from the CA server by your preferred method. Import the CA certificate into the Trusted Root Certification Authorities store: ```powershell theme={null} certutil -addstore Root "C:\_.crt" ``` The output should confirm the certificate was added: ```Text theme={null} CertUtil: -addstore command completed successfully. ``` Verify the test certificate contains the OCSP URL in its AIA extension: ```powershell theme={null} certutil -dump "C:\test_cert.cer" | findstr /i "ocsp" ``` The output should show the OCSP URL pointing to your OCSP server: `URL=http:///ocsp` If no OCSP URL is shown, the certificate was issued before the AIA extension was configured. Issue a new certificate and repeat this step. Run the end-to-end verification: ```powershell theme={null} certutil -verify -urlfetch "C:\test_cert.cer" ``` The output should include: ```Text theme={null} Verified "OCSP" Time: 0 [0.0] http:///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 (`+.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.