Skip to main content
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:
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.

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