> ## 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 the CA server for OCSP

> Configure the AIA and CDP extensions, publish the CRL, serve it through IIS, and create the OCSP response signing template on the CA server.

Configure the certificate authority to advertise the OCSP responder and publish its CRL.

## Configure AIA and CDP Extensions

> [!NOTE]
>
> This step must be performed on the CA server.
>
> * The **AIA / OCSP URL** must point to the **OCSP server**, where the Online Responder is
>   installed.
> * The **CDP / CRL URL** must point to the server that hosts the CRL through IIS:
>   * **Standalone CA:** the **OCSP server** (CRL files are copied there manually).
>   * **Enterprise CA:** the **CA server** (the CA publishes and serves its own CRL).

**Step 1**

Open the **Certification Authority** console by running the following command in an elevated
command prompt:

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

**Step 2**

In the console tree, right-click your CA name and select **Properties**.

**Step 3**

In the **CA Properties** window, select the **Extensions** tab.

**Step 4**

In the **Select extension** dropdown, select **CRL Distribution Point (CDP)**.

Select **\[ Add ]** and enter the CDP URL in the following format:

`http://<CRL-host-FQDN-or-IP>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl`

Replace the following:

* `<CRL-host-FQDN-or-IP>`: the host that serves the CRL through IIS:
  * **Standalone CA**: the OCSP server.
  * **Enterprise CA**: the CA server.
* `<CaName>`: the name of your CA (e.g., `Futurex-CA`).

> [!NOTE]
>
> Leave `<CRLNameSuffix>` and `<DeltaCRLAllowed>` exactly as shown. These are CA variables
> that Windows automatically substitutes with the correct values when publishing the CRL.

Select **\[ OK ]**.

In the list of CDP locations, select the URL you just added and check the following boxes:

* **Include in CRLs. Clients use this to find Delta CRL locations.**
* **Include in the CDP extension of issued certificates.**

**Step 5**

In the **Select extension** dropdown, select **Authority Information Access (AIA)**.

Select **\[ Add ]** and enter the OCSP URL in the following format:

`http://<OCSP-server-FQDN-or-IP>/ocsp`

Replace `<OCSP-server-FQDN-or-IP>` with the fully qualified domain name or IP address of
your OCSP server. Select **\[ OK ]**.

In the list of AIA locations, select the URL you just added and check **Include in the
online certificate status protocol (OCSP) extension**.

**Step 6**

Select **\[ Apply ]**. When prompted to restart Active Directory Certificate Services, select
**\[ Yes ]**.

> [!NOTE]
>
> These changes only apply to certificates issued after this configuration. Certificates
> issued before this change will not contain the OCSP or CDP URLs.

## Publish the CRL

> [!NOTE]
>
> Publishing the CRL makes it available for the OCSP server to download and use for revocation
> checking.

**Step 1**

Open the **Certification Authority** console:

```powershell theme={null}
certsrv.msc
```

**Step 2**

In the console tree, expand your CA name and right-click **Revoked Certificates**.

**Step 3**

Select **All Tasks** > **Publish**.

**Step 4**

In the **Publish CRL** dialog, select **New CRL** and select **\[ OK ]**.

**Step 5**

Verify the CRL was published by confirming the file exists:

```powershell theme={null}
dir "C:\Windows\System32\CertSrv\CertEnroll\*.crl"
```

> [!TIP]
>
> **Standalone CA**: One `.crl` file matching your CA name should be present. A standalone
> root CA doesn't publish a delta CRL by default. For example:
>
> ```Text theme={null}
> Futurex-CA.crl
> ```
>
> **Enterprise CA**: Two `.crl` files matching your CA name should be present:
>
> ```Text theme={null}
> Futurex-CA.crl     ← base CRL (full list of revoked certificates)
> Futurex-CA+.crl    ← delta CRL (changes since last base CRL)
> ```
>
> Both files are expected and normal for an Enterprise CA.

## Serve the CRL through IIS (Enterprise CA)

> [!NOTE]
>
> **Enterprise CA only.** Skip this section if you are using a Standalone CA. The CRL is served
> from the OCSP server's `CertEnroll` directory instead (see Configure Online Responder, Step 2).

On an Enterprise CA, the CA hosts its own CRL. Create an IIS virtual directory on the CA server
pointing to the AD CS `CertEnroll` directory.

**Step 1**

On the CA server, open **IIS Manager** (run `start inetmgr` from a command prompt, or open
it from **Server Manager** > **Tools** > **Internet Information Services (IIS) Manager**).

**Step 2**

In the left pane, expand the server node > **Sites** > **Default Web Site**. Right-click
**Default Web Site** and select **Add Virtual Directory**.

**Step 3**

Set the following and select **\[ OK ]**:

* **Alias:** `CertEnroll`
* **Physical path:** `C:\Windows\System32\CertSrv\CertEnroll`

**Step 4**

Enable double-escaping on the CertEnroll virtual directory so the delta CRL can be served.

> [!NOTE]
>
> **Why this is required.** The delta CRL filename contains a plus sign
> (`<CaName>+.crl`, e.g. `Futurex-CA+.crl`). By default, IIS request filtering blocks URLs
> containing the `+` character (it treats them as double-escaped) and returns
> **HTTP 404.11 (URL\_DOUBLE\_ESCAPED)**. The base CRL (`Futurex-CA.crl`) is unaffected and
> serves normally, so this only surfaces when a client tries to fetch the delta CRL.
>
> Because the base CRL is checked first, OCSP verification can succeed even while the delta
> CRL 404s. But in a longer-running environment where certificates are revoked between base
> CRL publishes, clients need the delta. Apply this fix so delta CRL retrieval works.
>
> Microsoft's guidance is to scope this change to the CRL-hosting site or virtual directory
> only, not server-wide. The scoped command below targets just `CertEnroll`.

Run **one** of the following on the CA server in an elevated prompt.

**Option 1: scoped to CertEnroll (recommended), `appcmd`:**

```cmd theme={null}
C:\Windows\System32\inetsrv\appcmd set config "Default Web Site/CertEnroll" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true
iisreset
```

**Option 2: scoped to CertEnroll, PowerShell equivalent:**

```powershell theme={null}
Set-WebConfigurationProperty -Filter "system.webServer/security/requestFiltering" -PSPath "IIS:\Sites\Default Web Site\CertEnroll" -Name "allowDoubleEscaping" -Value $true
iisreset
```

**Option 3: whole Default Web Site (fallback if the scoped path does not apply cleanly):**

```cmd theme={null}
C:\Windows\System32\inetsrv\appcmd set config "Default Web Site" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true
iisreset
```

> [!NOTE]
>
> You can also set this in the GUI: in IIS Manager, select the **CertEnroll** virtual
> directory, open **Request Filtering** > **Edit Feature Settings**, and check **Allow
> double escaping**. Then run `iisreset`.

**Step 5**

Verify both the base CRL and the delta CRL are reachable over HTTP. From the OCSP server (or
any other VM), run:

```powershell theme={null}
Invoke-WebRequest -Uri "http://<CA-server-IP>/CertEnroll/<CaName>.crl" -UseBasicParsing
Invoke-WebRequest -Uri "http://<CA-server-IP>/CertEnroll/<CaName>+.crl" -UseBasicParsing
```

> [!TIP]
>
> Both requests should show `StatusCode : 200` and `Content-Type: application/pkix-crl`. If
> the base CRL returns 200 but the delta (`+.crl`) returns 404, the double-escaping change
> did not take effect. Re-check which site/virtual directory you applied it to, confirm you
> ran `iisreset`, and try the broader Option 3 if you used a scoped option.

## Enable OCSP No-Check Flag

> [!NOTE]
>
> **Standalone CA only.** Skip this step if you are using an Enterprise CA. This flag allows the
> CA to issue OCSP signing certificates that are not themselves checked for revocation, which
> is required since the OCSP responder cannot check its own signing certificate's revocation
> status. Enterprise CA handles this automatically through the certificate template (the template
> includes the OCSP No-Check extension).

**Step 1**

Open an elevated command prompt and run the following command:

```powershell theme={null}
certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK
```

> [!TIP]
>
> The output shows the old and new values of `EditFlags`. The new value has the
> `EDITF_ENABLEOCSPREVNOCHECK` bit (`0x2000000`) set, and the output includes:
>
> ```Text theme={null}
>     EDITF_ENABLEOCSPREVNOCHECK -- 2000000 (33554432)
> CertUtil: -setreg command completed successfully.
> ```

**Step 2**

Restart the CA service for the change to take effect:

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

> [!TIP]
>
> Verify the CA service is running after the restart:
>
> ```powershell theme={null}
> Get-Service certsvc
> ```
>
> The status should show **Running**.

## Create and Publish the OCSP Response Signing Template

> [!NOTE]
>
> **Enterprise CA only.** Skip this section if you are using a Standalone CA. Standalone CA uses
> an INF file and `certreq` for OCSP signing certificate enrollment instead of an AD certificate
> template.

**Step 1**

On the CA server, open the Certificate Templates console:

```cmd theme={null}
certtmpl.msc
```

**Step 2**

In the list of templates, locate **OCSP Response Signing**, right-click it, and select
**Duplicate Template**.

**Step 3**

Configure the new template across the following tabs:

**General tab**

* Set **Template display name** to `OCSP Response Signing HSM`.

**Request Handling tab**

* Set **Purpose** to `Signature`.
* Leave **Allow private key to be exported** unchecked. The private key will remain
  protected inside the HSM.

**Cryptography tab**

* Set **Provider Category** to `Key Storage Provider`.

* Choose **one** algorithm and configure it consistently here and in the INF file in
  **Configure Online Responder, Create the OCSP Signing Certificate Request**:

  **RSA:**

  * Set **Algorithm name** to `RSA`.
  * Set **Minimum key size** to `2048`.

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

  * Set **Algorithm name** to `ECDSA_P384`.
  * Set **Minimum key size** to `384`.

* Select **Requests can use any provider available on the subject's computer**.

> [!NOTE]
>
> The algorithm you choose here must be used consistently throughout this guide. The INF
> file in **Configure Online Responder** must use the matching variant (RSA or ECC), and the
> test certificate in **Verify the integration** must match as well. Mixing algorithms across
> any of these steps will cause issuance or signing to fail.

> [!NOTE]
>
> The Futurex CNG KSP is specified at enrollment time on the OCSP server in the INF file.
> The template only needs to allow KSP providers generally. Even if `certutil -csplist`
> shows the Futurex provider as installed, it may not appear in the template's explicit
> provider list. Selecting "any provider" avoids this and is the correct choice here.

**Subject Name tab**

* Select **Build from this Active Directory information**.
* Set **Subject name format** to **Common name**.
* Under **Include this information in alternate subject name**, check **DNS name**.

> [!NOTE]
>
> This is the production-correct configuration. The CA populates the subject and the DNS
> Subject Alternative Name from the enrolling machine's trusted Active Directory computer
> object, rather than trusting a name supplied in the request. Because of this, the request
> must be submitted by the **machine account (SYSTEM)**. A request submitted
> by a normal user account will be denied with `CERTSRV_E_SUBJECT_DNS_REQUIRED`, because
> user objects do not have a `dNSHostName` attribute.

**Security tab**

* Confirm **Authenticated Users** has **Read** and **Enroll** permissions checked.

**Extensions tab**

* Click **Application Policies** > **Edit** and confirm **OCSP Signing**
  (`1.3.6.1.5.5.7.3.9`) is listed.

Click **OK** to save the template.

**Step 4**

Publish the template so the CA will issue certificates from it. In `certsrv.msc`, expand
your CA name, right-click **Certificate Templates** > **New** > **Certificate Template to
Issue**.

Select **OCSP Response Signing HSM** from the list and click **OK**.

> [!TIP]
>
> `OCSP Response Signing HSM` should now appear in the Certificate Templates list in the
> Certification Authority console.