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

# Operational considerations

> Performance, availability, and certificate lifecycle behavior specific to an HSM-backed IIS TLS key.

An HSM-backed TLS key changes some operational behavior that IIS administrators are accustomed to with software keys. Review these considerations before going to production.

## Handshake performance and session resumption

Every **full** TLS handshake requires a private key operation, which with this integration is a network round-trip to the CryptoHub. **Resumed** sessions (session tickets or IDs) do not use the private key, so resumption dramatically reduces HSM load on busy sites.

Plan for the added latency:

* A full handshake adds one CryptoHub round-trip to the connection setup. On a low-latency LAN
  between the IIS server and the CryptoHub, this is typically a few milliseconds; over a WAN it is
  dominated by network round-trip time. Keep the IIS server and CryptoHub on the same low-latency
  network segment where possible.
* Only the private key operation moves to the HSM. Symmetric encryption of the session, and all
  resumed handshakes, stay local to the IIS server, so steady-state throughput on established
  connections is unaffected.
* Enable TLS session resumption (the default in IIS/Schannel) so repeat clients avoid the HSM
  round-trip. On sites with high connection churn, resumption is the main lever for keeping HSM
  load and handshake latency low.

Benchmark full-handshake throughput against your own CryptoHub before sizing a high-traffic site, and confirm the expected private key operations per second with the CryptoHub team for your appliance model and network path.

## CryptoHub availability

The site can only complete full handshakes while the CryptoHub is reachable. Use CryptoHub's high-availability and failover capabilities, and monitor the IIS-to-CryptoHub path as a production dependency.

When the CryptoHub is unreachable during a handshake, expect the following:

* **Client-facing behavior.** New full handshakes fail, because Schannel cannot complete the
  server key operation. Clients see a connection reset or a TLS handshake failure rather than a
  certificate error. Clients on already-established or resumable sessions are unaffected until they
  need a new full handshake.
* **Server-side signal.** The FXCL provider cannot reach the appliance, so `fxcl.log` records a
  failed connection or handshake to the CryptoHub on port 2001, and Schannel logs a handshake
  failure in the Windows **System** event log (Schannel source). The IIS access log shows the
  request did not complete.

Alert on the IIS-to-CryptoHub path (port 2001 reachability) and on Schannel handshake-failure events so an outage surfaces before it affects a large share of clients. Confirm the exact client error text and Windows event IDs in your environment, because they vary by client and Windows version.

## Certificate renewal

The private key is non-exportable and resides in CryptoHub, which changes the usual renewal conveniences:

* **PFX export is not possible.** The certificate cannot be exported with its private key, moved
  between servers, or backed up as a `.pfx`. This is by design.
* **Renewal is a re-provision on the CryptoHub.** Renew by repeating the CryptoHub-side steps:
  generate a new key, issue a new certificate through PKI Management, and export the public
  certificate ([Create and export the key and certificate on the
  CryptoHub](/Integrations/CryptoHub/TLS_offloading/Microsoft_IIS/Create_the_key_and_certificate)),
  import and bind it on the IIS server ([Install the certificate on the IIS
  server](/Integrations/CryptoHub/TLS_offloading/Microsoft_IIS/Export_and_install_the_certificate)),
  then update the IIS binding to the new certificate ([Bind the certificate in
  IIS](/Integrations/CryptoHub/TLS_offloading/Microsoft_IIS/Bind_the_certificate_in_IIS)). Renewal
  is **not** done with `certreq` on the IIS server.

<Warning>
  Do not use IIS Manager's or the Certificates snap-in's built-in **Renew** action for a
  CryptoHub-backed certificate. That action assumes a locally generated key and a reachable issuing
  CA it can enroll against; with a non-exportable HSM key and CryptoHub as the CA, it cannot
  generate a matching request and fails or produces a certificate not bound to the CryptoHub key.
  Renew by re-provisioning on the CryptoHub as described above.
</Warning>

## Key hygiene

After you renew and confirm the new certificate is serving traffic, retire the old key on the CryptoHub so it cannot be used again:

* **Retire, do not immediately delete.** Confirm every IIS node is bound to the new certificate and
  serving handshakes before you remove the old key. Removing a key still bound on a node breaks that
  node's handshakes.
* **Remove the old key's authorization.** In **Key Management** > **Key Database**, remove the
  service role's **Use** permission on the retired key, or delete the key pair once no node depends
  on it. Revoke the old certificate in **PKI Management** > **Certificate Management** if your policy
  requires it.
* **Name keys for their site and rotation.** Give each key a recognizable name that ties it to the
  site and issue date (for example, `IIS TLS www.example.com 2026-07`), so you can locate the right
  key in the Key Database during renewal and retire the correct one afterward. A consistent naming
  convention is the main way to avoid retiring a live key by mistake.

Confirm your organization's retention and revocation requirements before deleting any key, and align the naming convention with how your team locates keys in the CryptoHub UI.