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 issuance policy 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.
Create an approval group
Create an approval group before you add the issuance policy; the policy references it as the certificate’s default approval group.1
In the CryptoHub web UI, go to PKI Management > PKI Signing Approvals.
2
Select [ Add Approval Group ] at the bottom of the page, or right-click anywhere in the
window and select Add Approval Group.
3
Enter
Microsoft IIS as the Name for the approval group and select [ OK ].4
Right-click the new approval group and select Permission.
5
In the first drop-down list, select the Microsoft IIS role (the role assigned to the
service you deployed), and select [ Add ].
6
In the Permission drop-down for the Microsoft IIS role, select the Use permission,
then select [ Save ].
The Microsoft IIS approval group exists, and the Microsoft IIS role has the Use
permission on it.
Add an issuance policy
The server certificate needs an issuance policy before the IIS server can use its key for TLS. Configure zero approvals so the CryptoHub answers handshakes without waiting for operator approval, then set the key’s security usage to Anonymous Signing.1
In PKI Management > Certificate Management, expand the
IIS TLS container to show both
the root CA and the leaf (server) certificate.2
Right-click the leaf (server) certificate and select Issuance Policy > Add.
3
In the Basic Info tab, set:
- Approvals:
0. A non-zero approval count means each private key operation waits for a human approval, which stalls TLS handshakes; use0for a server that must answer handshakes without operator interaction. A later step configures Anonymous Signing, so you can ignore the displayed warning Zero approval policy requires Anonymous Signing security usage. - Allowed hashes: SHA-256.
4
In the X.509 tab, set the Default approval group to Microsoft IIS.
5
Select [ OK ] to apply the issuance policy to the leaf certificate.
6
Right-click the leaf certificate and select Change Security Usage. In the Security
Usage drop-down, select Anonymous Signing, then select [ OK ].
In CryptoHub, Security Usage controls the authorization mode for each private key
operation, not the certificate’s TLS purpose. The TLS purpose comes from the Server
Authentication EKU you set in the V3 profile. Anonymous Signing lets the endpoint’s API
key authorize each signature on its own, which is what a TLS handshake needs; the appliance
also requires Anonymous Signing when the approval count is
0. This is the setting whose
absence caused the certreq path to fail with INVALID SECURITY USAGE.The leaf certificate has an issuance policy with Approvals
0, Allowed hashes
SHA-256, and Default approval group Microsoft IIS, and its Security Usage is
Anonymous Signing.Name the key and grant permissions
1
In the Key Database, give the generated key pair a recognizable name (for example,
IIS TLS).2
Grant the Microsoft IIS 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; it carries the issuance policy and
Anonymous Signing security usage; the key pair is present in the Key Database, and the
Microsoft IIS 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).