> ## 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 TLS integration, confirming IIS completes HTTPS handshakes using the CryptoHub HSM.

Verify that IIS serves HTTPS and that the TLS private key operation is performed in CryptoHub.

<Note>
  This is the critical verification for the entire integration. The handshake below is the first
  point at which Schannel, rather than `certreq`, drives the FXCL CNG provider.
</Note>

## Prerequisites

* The client machine can reach the IIS server on port 443.
* The issuing CA's certificate is trusted on the client machine (imported into Trusted Root
  Certification Authorities, or the CA chains to an existing trusted root).

## Option A: Verify from Linux

<Steps>
  <Step>
    Perform a TLS handshake and inspect the presented certificate:

    ```bash expandable lines wrap title="Bash" theme={null} theme={null}
    openssl s_client -connect <site-FQDN>:443 -servername <site-FQDN> -CAfile <ca>.pem
    ```

    <Check>
      The output should show the certificate chain with your site certificate's subject and the CA
      as issuer, and end with `Verify return code: 0 (ok)`.
    </Check>
  </Step>

  <Step>
    Confirm content is served over HTTPS:

    ```bash expandable lines wrap title="Bash" theme={null} theme={null}
    curl -v --cacert <ca>.pem https://<site-FQDN>/
    ```

    <Check>
      The response returns the site content with `HTTP/1.1 200` (or the site's expected status).
    </Check>
  </Step>
</Steps>

## Option B: Verify from Windows

<Steps>
  <Step>
    Request the site over HTTPS:

    ```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
    Invoke-WebRequest -Uri "https://<site-FQDN>/" -UseBasicParsing
    ```

    <Check>
      The output shows `StatusCode : 200` with no certificate trust errors.
    </Check>
  </Step>
</Steps>

## Confirm the handshake used the CryptoHub

<Steps>
  <Step>
    On the IIS server, check the FXCL log for the private key operation performed at handshake time:

    ```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
    Get-Content "C:\Program Files\Futurex\fxcl\kmes\cng\fxcl.log" -Tail 20
    ```

    <Check>
      With `log_level` set to `traffic`, the log shows a private key operation exchanged with the
      CryptoHub on port 2001, timestamped to the moment of the handshake. Expect a handshake to
      your CryptoHub followed by a private key (signing) command and its response, for example:

      ```text theme={null} theme={null}
      INFO   <cryptohub-host>:2001 handshake successful.
      TRAFFIC [<cryptohub-host>:2001] [Send] [AOSGNK;...]
      TRAFFIC [<cryptohub-host>:2001] [Recv] [AOSGNK;AN00;...]
      ```

      The key point is that a signing command reaches the CryptoHub at the moment IIS answers the
      client, which proves the private key operation ran in the HSM and not on the web server. Set
      `log_level` back to `info` for production after you confirm this. The exact command mnemonic
      Schannel drives can vary by CryptoHub build, so treat the lines above as representative rather
      than exact.
    </Check>
  </Step>

  <Step>
    Correlate with the IIS access log to confirm the request was served:

    ```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
    Get-Content "C:\inetpub\logs\LogFiles\W3SVC1\u_ex<YYMMDD>.log"
    ```

    <Check>
      An entry for your request exists with status `200` on port `443`, matching the timestamp of
      the FXCL log activity. This confirms the full chain: the client completed a TLS handshake with
      IIS, and the server's private key operation was performed in the CryptoHub HSM.
    </Check>
  </Step>
</Steps>