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

# Before you start

> Pre-deployment requirements, the certificate model, and CryptoHub permissions for the Microsoft IIS integration.

Verify your environment meets these requirements before you provision the IIS server certificate.

## Architecture

This guide assumes IIS is installed and serving the target site on a Windows Server. The FXCL CNG provider is installed on the **IIS server**, the machine where TLS handshakes terminate. The TLS key pair and its certificate are created on the **CryptoHub** through PKI Management; the IIS server holds only the public certificate plus a provider reference to the CryptoHub-resident key.

<Note>
  Because the private key is non-exportable and resides in CryptoHub, the usual web-farm approach
  of exporting a `.pfx` and copying it to every node does not apply. Two patterns work instead:

  * **Per-node certificates (Futurex recommends this).** Each IIS node deploys its own FXCL CNG
    endpoint (its own API key) and binds its own certificate to a CryptoHub-resident key. This
    keeps each node independently authenticated and auditable, and lets you revoke one node without
    affecting the others.
  * **Shared front-end termination.** Terminate TLS on a single front-end node (for example, an
    Application Request Routing or load-balancer tier) that holds the CNG endpoint and binding, and
    reach the back-end nodes over the internal network. Only the front-end node needs the FXCL CNG
    provider.

  A single shared key bound on multiple nodes is possible if each node's endpoint role is granted
  **Use** on the same key, but Futurex recommends per-node certificates for clearer revocation and
  auditing. Confirm the pattern for your topology with the CryptoHub team before you standardize on
  it.
</Note>

## Certificate model

<Note>
  **CryptoHub is the certificate authority for this integration.** You do not configure a
  Microsoft Standalone or Enterprise CA, and you do not run `certreq` to generate a key. Instead:

  * The TLS key pair is generated **on the CryptoHub** in a key store owned by the deployed
    service.
  * The server certificate is issued **on the CryptoHub** over that key through PKI Management
    (an X.509 container → CA → leaf with the **Server Authentication** EKU).
  * Only the **public** certificate (and its issuing CA chain) is exported and imported on the IIS
    server, then bound to the CryptoHub-resident key with `certutil -repairstore`.

  This is the same provisioning pattern the [**Windows Certificate Store**](/Integrations/CryptoHub/Certificate_management/Windows_Certificate_Store/Windows_Certificate_Store)
  integration guide uses. On CryptoHub `7.0.3.x`, client-side `certreq` key generation through the
  FXCL CNG provider is rejected by the appliance, which is why this CryptoHub-generated pattern is
  required.
</Note>

## Supported hardware

* CryptoHub **`7.0.3.x`**. This guide uses the **FXCL KMES CNG** provider (`libfxcl-cng.dll`),
  which is the `7.0.3.x`-and-older module. CryptoHub **`7.2` and later use a different CNG module**
  (the fxchlibs CNG Key Storage Provider, `cryptohub-cng.dll`, over REST on port 443). The steps
  in this guide do **not** apply to `7.2` or later.

## Supported operating systems

* Windows Server 2022 (validated).
* Windows Server 2012 R2 (6.3.9600) or later is expected to work, because the FXCL KMES CNG
  provider registers against the same CNG Key Storage Provider interface and Schannel present in
  those releases. Validate on your target Windows Server version before you rely on it in
  production.

## Required access

* An account on the CryptoHub with administrator permissions to deploy new services.
* Local administrator access on the Windows Server running IIS.

## Network and firewall

* Allow outbound TCP port **2001** (default Host API port) from the IIS server to the CryptoHub,
  specified by FQDN (for example, `cryptohub.example.com`) or CIDR (for example, `10.0.0.0/24`).
* Allow inbound TCP port **443** from clients to the IIS server.

<Warning>
  TLS inspection or SSL proxies can break mutual TLS handshakes. Exempt the CryptoHub FQDN(s) from
  inspection. Configure the CryptoHub with a FQDN so the exemption applies.
</Warning>

<Warning>
  The CryptoHub must be reachable when the site is serving HTTPS traffic; every full TLS
  handshake requires a private key operation in the HSM. Treat the IIS-to-CryptoHub path as
  production-critical and use CryptoHub's high-availability features.
</Warning>

## Prerequisites

* IIS is installed with the target site created and reachable over HTTP.
* CryptoHub `7.0.3.x` with PKI Management available, and administrator access to create an X.509
  container, a CA, and a key store (see [Create and export the key and certificate on the
  CryptoHub](/Integrations/CryptoHub/TLS_offloading/Microsoft_IIS/Create_the_key_and_certificate)).
  No separate Microsoft CA is required.