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

# Before you start

> Prepare the supported CryptoHub, Linux, Docker, Smallstep, identity, and network requirements for the step-ca integration.

Prepare the CryptoHub service, Linux host, network path, and protected storage before you configure step-ca.

## Supported versions

Use the following validated versions:

| Component | Version |
| - | - |
| CryptoHub | 7.3.0.x, build 7.3.0.0b or later in that branch |
| Host operating system | Ubuntu 24.04 x86-64 or a compatible Linux distribution |
| step-ca HSM image | `smallstep/step-ca:0.30.2-hsm` |
| step CLI | 0.30.6 |
| step-kms-plugin | 0.17.0 |
| Docker Engine | A version that supports bind mounts and supplementary groups |

<Warning>
  Do not run the CA with the standard `step-ca` package or release binary. Those builds reject `kms.type=pkcs11` because they lack CGO and PKCS #11 support. Run the pinned `0.30.2-hsm` image.
</Warning>

Pin the versioned HSM image instead of the moving `smallstep/step-ca:hsm` tag. A moving tag can change the CA, operating-system libraries, or plugin behavior without a configuration change.

## CryptoHub access

Obtain access to CryptoHub under dual control. The administrator workflow must allow you to:

* Deploy and manage the **Smallstep step-ca** service.
* Create a Linux OpenSSL 3.x client endpoint.
* Download the endpoint ZIP once. The ZIP contains the application credential and TLS material.

The deployed endpoint role supplies the runtime key and cryptographic permissions. Do not broaden its permissions unless a CryptoHub administrator has reviewed the change.

## Linux host

Prepare a Linux x86-64 host with:

* Root or `sudo` access, because the endpoint files require protected system locations.
* Docker Engine, because the HSM image supplies the PKCS #11-capable step-ca runtime.
* `curl`, `jq`, OpenSSL, and OpenSC, because the procedure verifies downloads, parses the endpoint config, and checks PKCS #11 connectivity.
* At least 2 GB of available memory and enough storage for the CA database, container image, and audit logs.

## Network and TLS

Allow these connections:

| Direction | Port | Purpose |
| - | - | - |
| step-ca host to CryptoHub | TCP 443 | FxChlibs REST and TLS transport |
| Certificate clients to step-ca host | TCP 9000, or your selected CA port | Certificate enrollment and CA health checks |

Add a TLS-inspection exemption for the CryptoHub connection. TLS interception changes the server certificate chain and prevents the endpoint from validating the appliance.

Verify reachability from the step-ca host:

```shell title="Shell" theme={null}
curl --connect-timeout 5 --head https://<cryptohub-host>
```

Replace `<cryptohub-host>` with the CryptoHub FQDN. An HTTP response proves that the network path is open; certificate validation may remain incomplete until you install the endpoint CA files.

## Protected storage

Prepare protected storage for:

* The endpoint ZIP and extracted `cryptohub.json`.
* The endpoint TLS client key and CA files.
* The encrypted software root key.
* The CA and provisioner password file.

Restrict these files to the step-ca operator and container runtime group. Do not place them in a source repository, container image, or command-line argument.

## Scope

This guide covers a single Linux CA node with a software root and a CryptoHub-backed online intermediate. It does not cover Windows, high availability, ACME, SSH CA operation, key rotation, or a native CGO source build.