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

# Configure Online Responder

> Procedural guide to configure the Online Responder (OCSP) role on the OCSP server and assign the HSM-backed signing certificate.

Configure the Online Responder (OCSP) role on the OCSP server and assign the HSM-backed signing
certificate so the responder can sign revocation responses using a key protected in the Excrypt HSM.

### Step 1: Configure the AD CS Configuration Wizard for Online Responder

**Step 1**

In **Server Manager**, select the flag icon to the left of **Manage** and select
**Configure Active Directory Certificate Services on the destination server**.

> [!NOTE]
>
> If the notification flag does not appear, the Online Responder role service may already be
> activated. In this case, proceed directly to **Step 6: Configure the Revocation
> Configuration** by opening `ocsp.msc`.

**Step 2**

On the **Credentials** page, verify your credentials meet the requirements and select
**\[ Next ]**.

> [!NOTE]
>
> **Enterprise CA only.** Configure the Online Responder while logged in as a domain
> administrator (for example, `LAB\Administrator`). Local administrator credentials are not
> sufficient.

**Step 3**

On the **Role Services** page, check **Online Responder** only and select **\[ Next ]**.

> [!NOTE]
>
> Do not check **Certification Authority** on the OCSP server. The CA role is only installed
> on the CA server.

**Step 4**

On the **Confirmation** page, select **\[ Configure ]**.

**Step 5**

On the **Results** page, select **\[ Close ]**.

### Step 2: Set Up CertEnroll on the OCSP Server

> [!NOTE]
>
> **Standalone CA only.** Skip this step if you are using an Enterprise CA. On an Enterprise CA,
> the CRL is served from the CA server's `CertEnroll` directory (see **Configure the CA server
> for OCSP**, "Serve the CRL through IIS"). On a dedicated Standalone OCSP server without the CA
> role, the CertEnroll folder is not created automatically and must be created manually.

**Step 1**

Open an elevated PowerShell prompt and create the CertEnroll folder:

```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
New-Item -Path "C:\CertEnroll" -ItemType Directory
```

**Step 2**

Create an IIS virtual directory pointing to the CertEnroll folder:

```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
New-WebVirtualDirectory -Site "Default Web Site" -Name "CertEnroll" -PhysicalPath "C:\CertEnroll"
```

**Step 3**

Verify the virtual directory was created successfully by opening **IIS Manager** and
confirming that **CertEnroll** appears under **Default Web Site**.

### Step 3: Copy CA Files to the OCSP Server

> [!NOTE]
>
> **Standalone CA only.** Skip this step if you are using an Enterprise CA.

**Step 1**

On the CA server, locate the CRL and CA certificate files:

```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
dir "C:\Windows\System32\CertSrv\CertEnroll\*"
```

Note the filenames of the `.crl` and `.crt` files.

**Step 2**

Copy the following files from the CA server to `C:\CertEnroll\` on the OCSP server:

* `<ServerHostname>_<CAName>.crt`: the CA certificate file
* `<CAName>.crl`: the base CRL file

Replace `<ServerHostname>` and `<CAName>` with the actual values from your environment.

**Step 3**

Verify the files are present on the OCSP server:

```powershell theme={null}
dir "C:\CertEnroll\*"
```

> [!TIP]
>
> Both the `.crl` and `.crt` files should be listed.

**Step 4**

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

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

Replace the filename with your actual CA certificate filename.

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

### Step 4: Create the OCSP Signing Certificate Request

> [!NOTE]
>
> **RSA or ECC.** This guide documents both an RSA and an ECC (ECDSA) OCSP signing key. Choose
> one and use the matching INF below. The choice must be consistent across the INF, the
> certificate template's Cryptography tab (Enterprise CA: see **Configure the CA server for
> OCSP**, "Create and Publish the OCSP Response Signing Template"), and your test certificate
> (see **Verify the integration**). If you mix them (for example, an ECDSA template with an RSA
> request), issuance or signing fails.

**Step 1**

On the OCSP server, create a new file named `ocsp_request.inf` by running the matching
command in an elevated PowerShell prompt.

> [!NOTE]
>
> The `ProviderName` value must exactly match the Futurex CNG provider name as it appears in
> the output of `certutil -csplist`. Verify this before proceeding.

> [!NOTE]
>
> **Keep the `KeyUsageProperty = NCRYPT_ALLOW_SIGNING_FLAG` line.** Both INFs require it.
> Without it, Futurex CNG creates a key that can encrypt and decrypt but can't sign, so
> `certreq` can't sign the request and fails: it can stop responding without output, or show
> an error. The failed attempt leaves the unused key on the HSM. In the
> `certutil -key -csp "Futurex CNG"` output it's the entry with no `AT_SIGNATURE` line; delete
> it as shown in the next step before you retry.

**RSA variant:**

```powershell theme={null}
@"
[Version]
Signature="`$Windows NT`$"

[NewRequest]
Subject = "CN=OCSP Signing"
KeyAlgorithm = RSA
KeyLength = 2048
HashAlgorithm = SHA256
MachineKeySet = TRUE
Exportable = FALSE
RequestType = CMC
ProviderName = "Futurex CNG"
KeyUsageProperty = NCRYPT_ALLOW_SIGNING_FLAG

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.9

[Extensions]
1.3.6.1.5.5.7.48.1.5 = Empty
"@ | Out-File -FilePath C:\ocsp_request.inf -Encoding ASCII
```

**ECC variant (ECDSA P-384):**

```powershell theme={null}
@"
[Version]
Signature="`$Windows NT`$"

[NewRequest]
Subject = "CN=OCSP Signing"
KeyAlgorithm = ECDSA_P384
KeyLength = 384
HashAlgorithm = SHA384
MachineKeySet = TRUE
Exportable = FALSE
RequestType = CMC
ProviderName = "Futurex CNG"
KeyUsageProperty = NCRYPT_ALLOW_SIGNING_FLAG

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.9

[Extensions]
1.3.6.1.5.5.7.48.1.5 = Empty
"@ | Out-File -FilePath C:\ocsp_request.inf -Encoding ASCII
```

> [!NOTE]
>
> **ECC key algorithm and key length.** Valid CNG ECDSA algorithm names are `ECDSA_P256`,
> `ECDSA_P384`, and `ECDSA_P521`. The `KeyLength` must match the curve in the algorithm name:
> `256` for `ECDSA_P256`, `384` for `ECDSA_P384`, `521` for `ECDSA_P521`. Pair the hash with
> the curve (SHA256 with P-256, SHA384 with P-384, SHA512 with P-521) so the signature
> strength is balanced. Adjust all three values together if you choose a different curve.
> `HashAlgorithm` in the INF only sets the request's signature. The OCSP responses use the
> revocation configuration's hash algorithm, which you set in **Step 7**.

> [!NOTE]
>
> **Do not include `ProviderType` in the INF.** `ProviderType` is a legacy CryptoAPI field.
> For CNG KSP requests it must be omitted, because its presence causes `ERROR_INVALID_DATA` for
> ECDSA requests.

> [!NOTE]
>
> **Enterprise CA.** The same INF (RSA or ECC) works for Enterprise CA. Do **not** add a
> Subject Alternative Name to the INF. The CA builds the subject and DNS SAN from Active
> Directory (configured on the template's Subject Name tab). Supplying a SAN in the request,
> or submitting as a user account, will result in `CERTSRV_E_SUBJECT_DNS_REQUIRED`. The
> request is submitted as the machine account in **Step 5: Submit, Issue, and Install the
> Signing Certificate**.

**Step 2**

Generate the certificate request:

```powershell theme={null}
certreq -new C:\ocsp_request.inf C:\ocsp_request.req
```

> [!TIP]
>
> Verify the request file was created:
>
> ```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
> Test-Path C:\ocsp_request.req
> ```
>
> The output should return `True`, and the `certreq` output should end with
> `CertReq: Request Created`, confirming the key was generated in the Excrypt HSM.
>
> For either variant, also check that no keys from earlier failed attempts were left behind:
>
> ```powershell theme={null}
> certutil -key -csp "Futurex CNG"
> ```
>
> Only the OCSP signing key should be listed. If keys from earlier failed attempts are
> present, delete each one by the name `certutil` lists:
>
> ```powershell theme={null}
> certutil -delkey -csp "Futurex CNG" "<key-name>"
> ```

### Step 5: Submit, Issue, and Install the Signing Certificate

> [!NOTE]
>
> This step differs depending on your CA type:
>
> * **Standalone CA**: The request is manually copied to the CA server, approved, and the
>   certificate copied back.
> * **Enterprise CA**: The request is submitted directly from the OCSP server using a scheduled
>   task running as **SYSTEM** (the machine account). No file copying or manual approval is
>   required. SYSTEM context is mandatory because the template builds the DNS name from the
>   machine's AD computer object.

#### Standalone CA

**Step 1**

Copy `C:\ocsp_request.req` from the OCSP server to the CA server.

**Step 2**

On the CA server, open the **Certification Authority** console (`certsrv.msc`). Right-click
your CA name and select **All Tasks** > **Submit New Request**. Browse to and select
`ocsp_request.req`.

**Step 3**

In the console tree, select **Pending Requests**. Right-click the submitted request and
select **All Tasks** > **Issue**.

**Step 4**

In the console tree, select **Issued Certificates**. Open the newly issued certificate, go
to the **Details** tab, and select **Copy to File**. Export the certificate as a **DER
encoded binary** `.cer` file named `ocsp_response.cer`.

**Step 5**

Copy `ocsp_response.cer` back to the OCSP server, then proceed to **Install the
Certificate** below.

#### Enterprise CA

For Enterprise CA, the certificate request must be submitted as the **machine account
(SYSTEM)** rather than as a domain user. This is required because the Enterprise CA looks up the
`dNSHostName` attribute from the requesting computer's Active Directory object to populate the
DNS Subject Alternative Name. A user account does not have this attribute, and the request will
be denied with `CERTSRV_E_SUBJECT_DNS_REQUIRED`.

A Windows scheduled task running as SYSTEM is used to submit the request without requiring
interactive tools like PsExec.

**Step 1**

On the OCSP server, open an elevated PowerShell prompt and create a scheduled task that
submits the certificate request as SYSTEM:

```powershell theme={null}
$action = New-ScheduledTaskAction -Execute "cmd.exe" -Argument '/c certreq -submit -config "<CA-Server-FQDN>\<CA-Name>" -attrib "CertificateTemplate:OCSPResponseSigningHSM" C:\ocsp_request.req C:\ocsp_response.cer > C:\certreq_output.txt 2>&1'
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -RunLevel Highest
$task = Register-ScheduledTask -TaskName "CertReqSubmit" -Action $action -Principal $principal
```

Replace the following:

* `<CA-Server-FQDN>`: the fully qualified domain name of your CA server (e.g.
  `ADCS.lab.local`).
* `<CA-Name>`: the name of your CA as shown in `certsrv.msc` (e.g. `Futurex-CA-ECDSA`).

> [!NOTE]
>
> The `-config` flag is required to specify the CA directly using its **FQDN**, not its IP
> address. Without it, or if an IP is used, `certreq` opens an interactive CA-selection
> popup which has nowhere to appear in the SYSTEM session and causes the task to hang
> indefinitely with an empty output file.

> [!NOTE]
>
> The `-attrib "CertificateTemplate:..."` value uses the template's **internal name**
> (no spaces), `OCSPResponseSigningHSM`, not the display name `OCSP Response Signing HSM`.

**Step 2**

Run the scheduled task and wait for it to complete:

```powershell theme={null}
Remove-Item C:\certreq_output.txt -ErrorAction SilentlyContinue
Start-ScheduledTask -TaskName "CertReqSubmit"
sleep 30
Get-Content C:\certreq_output.txt
```

> [!TIP]
>
> The output should contain:
>
> ```Text theme={null}
> 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 the output is empty after 30 seconds, check whether certreq is still running:
>
> ```powershell theme={null}
> Get-Process | Where-Object { $_.Name -match "certreq" }
> ```
>
> If a certreq process is present, it is hanging, most likely because the `-config` value
> uses an IP instead of an FQDN, or the task already exists from a previous run. Kill the
> process, unregister the task, and retry with the correct FQDN:
>
> ```powershell theme={null}
> Stop-Process -Name "certreq" -Force
> Unregister-ScheduledTask -TaskName "CertReqSubmit" -Confirm:$false
> ```
>
> If `ocsp_response.cer` already exists from a previous run, delete it before retrying:
>
> ```powershell theme={null}
> Remove-Item C:\ocsp_response.cer -ErrorAction SilentlyContinue
> ```

**Step 3**

Clean up the scheduled task:

```powershell theme={null}
Unregister-ScheduledTask -TaskName "CertReqSubmit" -Confirm:$false
```

#### Install the Certificate

Applies to both Standalone CA and Enterprise CA. Run these on the OCSP server.

**Step 1**

Install the certificate into the machine personal store:

```powershell theme={null}
certutil -addstore My C:\ocsp_response.cer
```

**Step 2**

Find the serial number of the issued certificate:

```powershell theme={null}
certutil -dump C:\ocsp_response.cer | findstr "Serial Number"
```

**Step 3**

Link the certificate to the HSM private key:

```powershell theme={null}
certutil -repairstore My "<Serial_Number>"
```

Replace `<Serial_Number>` with the value from the previous step.

**Step 4**

Verify the certificate was installed and linked to the HSM key:

```powershell theme={null}
certutil -store My
```

> [!TIP]
>
> Locate the OCSP Signing certificate in the output and confirm the following fields are
> present:
>
> ```Text theme={null}
> Provider = Futurex CNG
> Private key is NOT exportable
> Signature test passed
> ```
>
> If `Signature test passed` does not appear, the certificate is not properly linked to the
> HSM key. Repeat the `certutil -repairstore` command and verify again.

### Step 6: Configure the Revocation Configuration

**Step 1**

Open the **Online Responder Management** console:

```powershell expandable lines wrap title="Command Prompt" theme={null} theme={null}
ocsp.msc
```

**Step 2**

In the console tree, right-click **Revocation Configuration** and select **Add Revocation
Configuration**.

**Step 3**

On the **Getting Started** page, select **\[ Next > ]**.

**Step 4**

On the **Name the Revocation Configuration** page, enter a name for the configuration. It is
recommended to include the CA name. Select **\[ Next > ]**.

**Step 5**

On the **Select CA Certificate Location** page:

* **Standalone CA:** Select **A certificate from the Local certificate store** and select
  **\[ Next > ]**, then **\[ Browse... ]** to select your CA certificate from the list.
* **Enterprise CA:** Select **Select a certificate for an Existing Enterprise CA** and
  select **\[ Next > ]**, then **\[ Browse... ]** to select your CA from those published in
  Active Directory.

Select **\[ Next > ]**.

**Step 6**

On the **Select Signing Certificate** page, select **Manually select a signing
certificate**.

> [!NOTE]
>
> For both CA types in this guide, the HSM-backed signing certificate was enrolled and
> installed manually in **Step 5: Submit, Issue, and Install the Signing Certificate** so
> that the Futurex CNG provider could be specified. Do not use the wizard's auto-enroll
> option. It would attempt to enroll a new key outside the INF workflow and would not use
> the HSM provider. The signing certificate is assigned in **Step 7: Assign the Signing
> Certificate**.

Select **\[ Next > ]**.

**Step 7**

On the **Revocation Provider** page, select **\[ Provider... ]**.

> [!NOTE]
>
> An error pop-up may appear saying **Element not found**. This can be ignored by selecting
> **\[ OK ]**.

* **Standalone CA:** Select **\[ Add ]** under **Base CRLs** and enter your CA's CRL URL:

  `http://<OCSP-server-FQDN-or-IP>/CertEnroll/<CAName>.crl`

  Then select **\[ OK ]**.

* **Enterprise CA:** CRL URLs are populated automatically from Active Directory and from the
  CDP extension. Verify they are correct. The HTTP entry should point to the **CA server**
  (e.g. `http://<CA-server-IP>/CertEnroll/<CAName>.crl`). If an old or incorrect URL is
  present and the **Edit**/**Delete** buttons are unavailable, delete the revocation
  configuration and recreate it. Recreating pulls the current URLs from the updated CA
  certificate.

Set the **Update CRLs at this refresh interval (min)** to your organization's needs. In this
example, `15` minutes was used.

Select **\[ OK ]** then **\[ Finish ]**.

### Step 7: Assign the Signing Certificate

> [!NOTE]
>
> Applies to both CA types in this guide, because the HSM-backed signing certificate was
> enrolled manually in **Step 5: Submit, Issue, and Install the Signing Certificate**.

**Step 1**

In the **Online Responder Management** console, expand **Array Configuration** and select
your OCSP server.

**Step 2**

In the center pane, right-click the Revocation Configuration you created and select **Assign
Signing Certificate**.

**Step 3**

Select the OCSP signing certificate you installed in **Step 5: Submit, Issue, and Install
the Signing Certificate** and select **\[ OK ]**.

**Step 4**

Right-click the Revocation Configuration, select **Edit Properties**, and on the **Signing**
tab set **Hash algorithm** to match the signing key: SHA256 for RSA and ECDSA P-256, SHA384
for ECDSA P-384, SHA512 for ECDSA P-521. Select **\[ OK ]**.

> [!NOTE]
>
> The Online Responder signs each response with this hash, not with the INF's
> `HashAlgorithm`. With the default (SHA256), a P-384 signing key still produces
> `ecdsa-with-SHA256` responses.

**Step 5**

Restart the Online Responder service so it loads the new signing key from the HSM:

```powershell theme={null}
Restart-Service OcspSvc
```

The service reads the HSM's key list when it starts, so a key created after it started
isn't found until the restart. Without it, the status in **Step 8** shows a keyset error.

> [!NOTE]
>
> If you replace the signing certificate of an existing revocation configuration later (for
> example, to renew it or to switch between RSA and ECDSA), also recycle the IIS application
> pool. It caches responses, so clients keep receiving responses signed by the previous key
> until it's recycled:
>
> ```powershell theme={null}
> Restart-WebAppPool OCSPISAPIAppPool
> ```

### Step 8: Verify the Configuration

**Step 1**

In the **Online Responder Management** console, right-click **Array Configuration** and
select **Refresh Revocation Data**.

**Step 2**

Expand **Array Configuration** and select your OCSP server. In the center pane, verify that
the **Revocation Configuration Status** shows **Working** (green checkmark) and that a
signing certificate is present.

> [!NOTE]
>
> The Online Responder service loads the Futurex CNG provider when it starts and doesn't
> retry a signing key it can't open. If the status shows an error (for example, a keyset
> error), or if the HSM was unreachable when the service started, restart the service again
> and refresh the status:
>
> ```powershell theme={null}
> Restart-Service OcspSvc
> ```

> [!NOTE]
>
> If you see leftover revocation configurations from earlier attempts showing errors (for
> example, **Bad signing certificate on Array controller**), delete them. If an old array
> controller (a previous server name) is listed, remove it as well. Your new configuration
> must appear under the current OCSP server node (e.g. `OCSP.lab.local`).

**Step 3**

Verify the CA service is reachable from the OCSP server:

```powershell theme={null}
certutil -ping -config "<CA-Server-FQDN>\<CA-Name>"
```

Replace `<CA-Server-FQDN>` with the fully qualified domain name of your CA server and
`<CA-Name>` with your CA name (e.g., `Futurex-CA`).

> [!TIP]
>
> The output should confirm the CA is alive:
>
> ```Text theme={null}
> CertUtil: -ping command completed successfully.
> ```