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

# Generate a code signing key pair

> Step-by-step guide to generate a code signing key pair on the CryptoHub with Java keytool for later use with JSign.

This section uses Java **keytool** to generate a new code signing key pair on the CryptoHub, which JSign uses later to sign artifacts. On **FXPKCS11 6.0 rev dc27 or later**, this single command generates the key pair on the CryptoHub and produces a usable `PrivateKeyEntry` with no CryptoHub UI step.

JSign consumes the CryptoHub token directly through the SunPKCS11 provider, so there is no separate Java KeyStore file to create or manage. The key and its certificate live on the appliance.

<Note>
  The JDK installation includes the `keytool` application that enables you to run the `keytool` commands in this section with no additional configuration.
</Note>

## Generate a key pair

Perform the following steps to generate a key pair on the CryptoHub:

<Steps>
  <Step>
    Export **FXPKCS11\_CFG** so the Futurex PKCS #11 library can locate its configuration file (`fxpkcs11.cfg`). Point it at the `fxpkcs11.cfg` you configured in [Install and configure Futurex PKCS #11](/Integrations/CryptoHub/Code_signing/JSign/Install_and_configure_Futurex_PKCS_11):

    ```shell expandable lines wrap title="Shell" theme={null}
    export FXPKCS11_CFG=/etc/fxpkcs11.cfg
    ```

    <Note>
      On Windows, set `FXPKCS11_CFG` as a machine-wide variable with `setx` instead (see [Configure SunPKCS11 to use the Futurex PKCS11 module](/Integrations/CryptoHub/Code_signing/JSign/Configure_SunPKCS11_to_use_the_Futurex_PKCS11_module)). If you set `fxpkcs11.cfg` in its default location, this step is not required.
    </Note>
  </Step>

  <Step>
    Execute the following command, passing the `pkcs11.cfg` file you created in the previous section with `-providerArg`. Set `-alias` and `-dname` to a value that identifies this signing key:

    ```text expandable lines wrap title="Text" theme={null}
    keytool -genkeypair -alias jsign-demo -keyalg RSA -keysize 3072 -sigalg SHA384withRSA -dname "CN=jsign-demo, O=Futurex" -validity 365 -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg /usr/local/etc/pkcs11.cfg -providerName SunPKCS11-Futurex -ext extendedKeyUsage=codeSigning -ext KeyUsage=digitalSignature
    ```

    <Note>
      On Windows, run the same command in a Command Prompt window and replace `/usr/local/etc/pkcs11.cfg` with the path to your `pkcs11.cfg` file, such as `C:\path\to\pkcs11.cfg`.
    </Note>

    <Note>
      This command uses RSA 3072, which is the key size Futurex validated for this integration and the minimum that current code signing certificate requirements expect. RSA 2048 also works with this flow if your signing policy calls for it.

      `-sigalg SHA384withRSA` sets the signature algorithm of the self-signed certificate that keytool creates alongside the key. It matches the SHA-384 digest the JSign examples use. It does not constrain the digest you pass to JSign later, so `SHA256withRSA` is also valid.

      The two `-ext` flags put the code signing extended key usage and the `digitalSignature` key usage on the generated certificate, which is what an Authenticode signing certificate requires.
    </Note>

    <Warning>
      All three provider flags are required and case-sensitive: `-providerClass`, `-providerArg`, and `-providerName`. If you misspell them or omit `-providerName`, SunPKCS11 falls back to generating the key in software and importing it, which defeats the purpose of the integration and fails on the CryptoHub.
    </Warning>

    <Check>
      The keytool application generates the key pair on the CryptoHub and self-signs a certificate for it. With no `-storepass` on the command line, keytool prompts for the KeyStore password.
    </Check>
  </Step>

  <Step>
    When prompted for the KeyStore password, enter the CryptoHub identity password (PKCS #11 PIN) configured inside the `<CRYPTO-OPR-PASS>` tag in the `fxpkcs11.cfg` file.

    <Note>
      Let keytool prompt for the PIN rather than passing `-storepass` on the command line. A PIN supplied as an argument is visible in your shell history and in the system process list.
    </Note>
  </Step>
</Steps>

## Verify the key pair

Run the following **keytool** command to confirm the key pair generated on the CryptoHub and lists a `PrivateKeyEntry`:

```shell expandable lines wrap title="Shell" theme={null}
keytool -list -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg /usr/local/etc/pkcs11.cfg -providerName SunPKCS11-Futurex
```

<Check>
  The response is similar to the following:

  ```shell expandable lines wrap title="Shell" theme={null}
  Keystore type: PKCS11
  Keystore provider: SunPKCS11-Futurex

  Your keystore contains 1 entry

  jsign-demo-1785267399:jsign-demo, PrivateKeyEntry,
  Certificate fingerprint (SHA-256): C0:05:05:D8:F8:5E:B9:FE:DA:52:C3:C3:56:05:E8:1F:F3:0A:15:73:D1:6D:FE:9A:91:27:2D:E1:EF:58:C5:B4
  ```
</Check>

<Warning>
  The CryptoHub assigns the on-token key its own alias in the form `<alias>-<id>:<alias>` (for example, `jsign-demo-1785267399:jsign-demo`), where `<id>` is generated per key. This alias, not the short `-alias` value you passed to `keytool -genkeypair`, is what JSign and other tools must reference. The `<id>` value differs every time you generate a key, so you cannot predict it: copy the exact alias from this `keytool -list` output for the signing commands in [JSign command examples](/Integrations/CryptoHub/Code_signing/JSign/JSign_command_examples).
</Warning>

<Note>
  The subject distinguished name is unaffected by the alias form. It comes from `-dname`, so `CN=jsign-demo` holds for any downstream check against the certificate subject.
</Note>

<Check>
  If `keytool -list` reports 0 entries after a successful `-genkeypair`, the library is not pairing the certificate with the private key. Confirm you replaced the bundled FXPKCS11 4.59 library with **6.0 rev dc27 or later**, and confirm both `attributes(generate, ...)` blocks are present in `pkcs11.cfg`.
</Check>