> ## 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 Excrypt HSM.

Verify that the OCSP responder signs responses using the Excrypt HSM end to end.

> [!NOTE]
>
> The following verification 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
> Excrypt 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.

> [!NOTE]
>
> 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.

> [accordion] How to issue a test certificate
>
> > [!NOTE]
> >
> > **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 from `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.
>
> > [!NOTE]
> >
> > **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 `<CA-Server-FQDN>\<CAName>` 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 "<CA-Server-FQDN>\<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:
>
> ```powershell theme={null}
> @"
> [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
> ```
>
> > [!TIP]
> >
> > The submit output should end with `Certificate retrieved(Issued) Issued`.
> >
> > > [!NOTE]
> > >
> > > The repeated word is expected: `(Issued)` is the status code returned by `certreq` and
> > > `Issued` is the CA's disposition string.
> >
> > If it shows `Certificate request is pending: Taken Under Submission` (Standalone CA with
> > manual approval), note the `RequestId` in the same output, issue the request on the CA in
> > `certsrv.msc` > **Pending Requests** > **All Tasks** > **Issue**, then retrieve it:
> >
> > ```powershell theme={null}
> > certreq -retrieve -f -config "<CA-Server-FQDN>\<CAName>" <RequestID> C:\test_cert.cer
> > ```
> >
> > > [!NOTE]
> > >
> > > The `-f` option replaces the `.rsp` file that the earlier `certreq -submit` left next to
> > > the certificate. Without it, `certreq` stops at a prompt.
>
> Copy `C:\test_cert.cer` to the client machine before proceeding with verification.
>
> > [!NOTE]
> >
> > 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

**Step 1**

Verify `openssl` is installed:

```bash theme={null}
openssl version
```

If not installed, run:

```bash theme={null}
sudo apt install openssl -y
```

> [!TIP]
>
> The output should show the OpenSSL version, for example `OpenSSL 3.0.2 15 Mar 2022`.

**Step 2**

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://<CA-server-FQDN>/CertEnroll/<ServerHostname>_<CAName>.crt
```

Otherwise, copy the `.crt` from the CA server by your preferred method.

**Step 3**

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
```

> [!TIP]
>
> 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
> ```

**Step 4**

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
  ```

**Step 5**

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"
```

> [!TIP]
>
> The output should show the OCSP URL pointing to your OCSP server:
>
> `OCSP - URI:http://<OCSP-server-IP>/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.

**Step 6**

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-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.

> [!TIP]
>
> The output should confirm a successful OCSP response:
>
> ```Text theme={null}
> 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 Excrypt HSM.

**Step 7**

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<YYMMDD>.log
```

Replace `<YYMMDD>` with today's date, for example `u_ex260603.log` for June 3, 2026.

> [!TIP]
>
> 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
> Excrypt HSM.

### Option B: Verify from Windows

**Step 1**

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://<CA-server-FQDN>/CertEnroll/<ServerHostname>_<CAName>.crt" -OutFile "C:\<ServerHostname>_<CAName>.crt" -UseBasicParsing
```

Otherwise, copy the `.crt` from the CA server by your preferred method.

**Step 2**

Import the CA certificate into the Trusted Root Certification Authorities store:

```powershell theme={null}
certutil -addstore Root "C:\<ServerHostname>_<CAName>.crt"
```

Use the actual CA certificate filename from your environment.

> [!TIP]
>
> The output should confirm the certificate was added:
>
> ```Text theme={null}
> CertUtil: -addstore command completed successfully.
> ```

**Step 3**

Verify the test certificate contains the OCSP URL in its AIA extension:

```powershell theme={null}
certutil -dump "C:\test_cert.cer" | findstr /i "ocsp"
```

> [!TIP]
>
> The output should show the OCSP URL pointing to your OCSP server:
>
> `URL=http://<OCSP-server-IP>/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.

**Step 4**

Run the end-to-end verification:

```powershell theme={null}
certutil -verify -urlfetch "C:\test_cert.cer"
```

> [!TIP]
>
> The output should include:
>
> ```Text theme={null}
> 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.
>
> > [!NOTE]
> >
> > **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 through 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.