> ## 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 via 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 via 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).
</Note>

<Steps>
  <Step>
    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>

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

  <Step>
    In the **CA Properties** window, select the **Extensions** tab.
  </Step>

  <Step>
    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 via 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.
    </Note>

    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>

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

  <Step>
    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.
    </Note>
  </Step>
</Steps>

## Publish the CRL

<Note>
  Publishing the CRL makes it available for the OCSP server to download and use for revocation
  checking.
</Note>

<Steps>
  <Step>
    Open the **Certification Authority** console:

    ```powershell theme={null}
    certsrv.msc
    ```
  </Step>

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

  <Step>
    Select **All Tasks** > **Publish**.
  </Step>

  <Step>
    In the **Publish CRL** dialog, select **New CRL** and select **\[ OK ]**.
  </Step>

  <Step>
    Verify the CRL was published by confirming the file exists:

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

    <Check>
      **Standalone CA** — One `.crl` file matching your CA name should be present, 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.
    </Check>
  </Step>
</Steps>

## Serve the CRL via IIS (Enterprise CA)

<Note type="warning">
  **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).
</Note>

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.

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

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

  <Step>
    Set the following and select **\[ OK ]**:

    * **Alias:** `CertEnroll`
    * **Physical path:** `C:\Windows\System32\CertSrv\CertEnroll`
  </Step>

  <Step>
    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`.
    </Note>

    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`.
    </Note>
  </Step>

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

    <Check>
      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.
    </Check>
  </Step>
</Steps>

## Enable OCSP No-Check Flag

<Note type="warning">
  **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 via the certificate template (the template
  includes the OCSP No-Check extension).
</Note>

<Steps>
  <Step>
    Open an elevated command prompt and run the following command:

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

    <Check>
      The output should show the old and new values of the flag, confirming it was set
      successfully. For example:

      ```Text theme={null}
      ...PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

      Old Value:
          EditFlags REG_DWORD = 11014e (1118542)

      New Value:
          EditFlags REG_DWORD = 11054e (1115470)
      CertUtil: -setreg command completed successfully.
      ```
    </Check>
  </Step>

  <Step>
    Restart the CA service for the change to take effect:

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

    <Check>
      Verify the CA service is running after the restart:

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

      The status should show **Running**.
    </Check>
  </Step>
</Steps>

## Create and Publish the OCSP Response Signing Template

<Note type="warning">
  **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.
</Note>

<Steps>
  <Step>
    On the CA server, open the Certificate Templates console:

    ```cmd theme={null}
    certtmpl.msc
    ```
  </Step>

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

  <Step>
    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 Step 4:

      **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, Create the OCSP Signing Certificate Request** 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>

    **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.
    </Note>

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

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

    <Check>
      `OCSP Response Signing HSM` should now appear in the Certificate Templates list in the
      Certification Authority console.
    </Check>
  </Step>
</Steps>