Skip to main content
On CryptoHub 7.0.3.x, the TLS key and its certificate are created on the appliance, not on the IIS server. You do this once in the CryptoHub web UI through PKI Management, then export the public certificate at the end of this section for installation on the IIS server (Install the certificate on the IIS server).
Why not certreq? On CryptoHub 7.0.3.x, generating the key from Windows with certreq -new through the FXCL CNG provider is rejected by the appliance. The provider logs in and reaches the CryptoHub, but the key-generation request fails with INVALID SECURITY USAGE / INVALID KEY USAGE (surfaced as NTE_INTERNAL_ERROR 0x8009002d), because the client cannot set the security usage the appliance requires for the key. Creating the key and certificate on the CryptoHub, where the appliance sets the security usage, is the supported path, matching the Windows Certificate Store guide.

​
Create the certificate on the CryptoHub

1
In the CryptoHub web UI, go to PKI Management > Certificate Management and create a new X.509 container (for example, IIS TLS). Set the container owner to the role of the service you deployed.
2
In the container, generate a Root CA certificate (V3 profile Certificate Authority), for example CN IIS TLS Root. This CA signs the server certificate and is the trust anchor clients must trust.
If you already operate a CryptoHub CA you want to chain to, issue the leaf under that CA instead of creating a new root. Clients must trust whichever CA is the chain’s root.
3
Issue a leaf certificate under that CA for the site. Right-click the CA certificate and select Add Certificate > New Certificate, then configure:
  • Subject DN: Preset Classic, Common Name = the site FQDN (for example, www.example.com).
  • V3 Extensions: set the Profile to TLS Server Certificate, which applies the Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1) the certificate needs to authenticate an HTTPS server. (The Windows Certificate Store guide uses the TLS Client Certificate profile; for an IIS server certificate you use TLS Server Certificate instead.)
  • Subject Alternative Name: every hostname clients use to reach the site (for example, www.example.com, example.com). Modern browsers ignore the CN and require a matching SAN entry. In the certificate creation wizard, add these on the Subject Alternative Name (or SAN) tab as DNS entries, one per hostname. Add an IP Address SAN entry only if clients connect to the site by IP.
  • Key: RSA 2048 (or your standard), generated into the service’s key store.
A TLS server certificate without a SAN entry matching the hostname fails validation in modern browsers, even when the CN matches. Confirm every hostname clients use is present as a DNS SAN entry before you issue the certificate. If your 7.0.3.x PKI Management wizard does not expose a SAN field for the leaf profile, reissue the leaf using a V3 profile that includes the Subject Alternative Name extension, or contact Futurex support for the profile that enables it.
4
In the Key Database, give the generated key pair a recognizable name (for example, IIS TLS) and grant the service role the Use permission on both the key and the issued certificate.
The leaf certificate is issued and visible in the container, chained to the CA, with the Server Authentication EKU and the SAN entries you set; the key pair is present in the Key Database and the service role has Use.

​
Export the certificate from the CryptoHub

1
In PKI Management > Certificate Management, export the leaf (server) certificate as a PEM/DER file, and export the CA certificate (the root, and any intermediates) as PEM. Export public certificates only; do not export the private key (it is non-exportable and must remain on the CryptoHub).
2
Copy the exported certificate files to the IIS server (for example, to C:\stage).
Continue to Install the certificate on the IIS server to import the certificate and bind it on the IIS server.