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

# Create and export the key and certificate on the CryptoHub

> Generate the TLS key pair, issue the server certificate on the CryptoHub through PKI Management, and export the public certificate for the IIS server.

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](/Integrations/CryptoHub/TLS_offloading/Microsoft_IIS/Export_and_install_the_certificate)).

<Note>
  **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.
</Note>

## Create the certificate on the CryptoHub

<Steps>
  <Step>
    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.
  </Step>

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

    <Note>
      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.
    </Note>
  </Step>

  <Step>
    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**.

    <Warning>
      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.
    </Warning>
  </Step>

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

    <Check>
      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**.
    </Check>
  </Step>
</Steps>

## Export the certificate from the CryptoHub

<Steps>
  <Step>
    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).
  </Step>

  <Step>
    Copy the exported certificate files to the IIS server (for example, to `C:\stage`).
  </Step>
</Steps>

Continue to [Install the certificate on the IIS server](/Integrations/CryptoHub/TLS_offloading/Microsoft_IIS/Export_and_install_the_certificate) to import the certificate and bind it on the IIS server.