step-ca

Sign in to the Azure portal, select Create a resource and search the Marketplace for step-ca by SecureAnyCloud. Select the SecureAnyCloud listing and choose Create.

On the Basics tab, pick your subscription, resource group and region, and a VM size of Standard_B2s or larger. Under Administrator account, select SSH public key, set the username to azureuser and supply your public key. Under Inbound port rules, allow SSH (22) only. On the Networking tab, choose your virtual network and subnet. Then select Review + create and Create.

First-boot initialization generates the VM's own unique certificate authority. It takes a short moment after the VM state becomes Running. step-ca.service is serving its API by the time you can connect.

The following command launches a VM from the SecureAnyCloud step-ca image into an existing resource group. Replace the values in angle brackets with your own. The image reference comes from the Usage information of the Marketplace listing.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:step-ca-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-resource-group> \
  --name step-ca \
  --image sac1647283583153:step-ca-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard

When the VM reaches the Running state, note its public IP address from the portal or with az vm list-ip-addresses.

Connect over SSH as azureuser with your key pair.

ssh azureuser@<vm-ip>

The login banner lists the most useful commands. The CA is already running and healthy.

Confirm the installed step-ca and step versions, and that the certificate authority daemon is active. step-ca is the CA server, and step is the client command-line tool.

step-ca version step version systemctl is-active step-ca

The service is active. The version is the pinned 0.30.2 release of step-ca, with the matching 0.30.6 step CLI.

step-ca serves its X.509 and ACME API over TLS on the loopback address 127.0.0.1:8443. The API uses the CA's own certificate chain, which is rooted in this VM's unique CA root rather than a public PKI. Query the health endpoint with curl -k.

curl -k https://127.0.0.1:8443/health
sudo ss -tln | grep 8443

The health endpoint returns {"status":"ok"}. The listener is bound to 127.0.0.1:8443 only, so the CA is not exposed on any external interface.

On its first boot, this VM generated its own random certificate authority key password and provisioner password, and initialized a new certificate authority unique to this VM. The generated passwords, the provisioner name and the root certificate fingerprint are written to a root-only file. Read them as follows.

sudo cat /root/step-ca-credentials.txt

Keep these values safe. The provisioner password authorizes certificate issuance, and clients pin the root fingerprint when they bootstrap against your CA.

The CA has a password-protected JWK provisioner named admin. Bootstrap a local client against the CA with the root fingerprint, then issue a short-lived leaf certificate. The following command reads the provisioner password and the root fingerprint from the credentials file, so it runs end to end without prompting.

export STEPPATH="$HOME/.step-demo"
FP=$(sudo grep '^stepca.root.fingerprint=' /root/step-ca-credentials.txt | cut -d= -f2-) printf '%s' "<STEPCA_PROVISIONER_PASSWORD>" > /tmp/prov.pass chmod 600 /tmp/prov.pass step ca bootstrap --ca-url https://127.0.0.1:8443 --fingerprint "$FP" --force step ca certificate web.internal /tmp/web.crt /tmp/web.key \
  --provisioner admin --provisioner-password-file /tmp/prov.pass --not-after 24h --force rm -f /tmp/prov.pass

The step tool prints the provisioner, the CA URL and the paths of the issued certificate and private key. You now have a short-lived TLS certificate signed by your private CA.

The root certificate is public material that clients trust. Inspect it and read its fingerprint with the step tool.

sudo -u step env STEPPATH=/var/lib/step-ca step certificate inspect /var/lib/step-ca/certs/root_ca.crt --short sudo -u step env STEPPATH=/var/lib/step-ca step certificate fingerprint /var/lib/step-ca/certs/root_ca.crt

The root certificate is an ECDSA P-256 CA certificate, valid for ten years and self-signed by this VM's own certificate authority.

By default the CA listens on loopback only, so only the VM itself can reach it. To let other hosts request certificates, do two things. Open the CA port in this VM's network security group, and make the CA reachable on a routable address.

To reach the running CA from your workstation without changing its binding, open an SSH tunnel.

ssh -L 8443:127.0.0.1:8443 azureuser@<vm-ip>

With the tunnel up, point a client at https://127.0.0.1:8443 from your workstation and bootstrap it with the root fingerprint shown in the credentials file.

To expose the CA to your network directly, add an inbound NSG rule for TCP 8443 from the client networks that need certificates. Then re-initialize or reconfigure the CA so that its address and DNS names match the routable address. Never open 8443 to the public internet without restricting the source ranges to the clients that need it.

A default ACME provisioner is configured, so standard ACME clients can request and renew certificates automatically. Point any ACME client at the CA's ACME directory.

https://<ca-host>:8443/acme/acme/directory

Give the client the CA root certificate as its trust anchor. The public root_ca.crt is under /var/lib/step-ca/certs. ACME clients then request and renew short-lived certificates against your private CA with no manual steps.

The certificate authority reads its configuration from a single JSON file. All CA material lives on the dedicated data disk mounted at /var/lib/step-ca.

• /var/lib/step-ca/config/ca.json is the main configuration. Use it to add and remove provisioners, adjust certificate lifetimes and templates, enable SSH certificates and point ACME clients at the directory.
• /var/lib/step-ca/certs/ holds the public root and intermediate certificates.
• /var/lib/step-ca/secrets/ holds the encrypted signing keys, readable only by the step user.

After you edit ca.json, reload the CA so that it picks up the change.

sudo systemctl reload step-ca systemctl is-active step-ca

The CA material sits on an independently resizable Azure data disk that is separate from the operating system disk. You can grow the disk and snapshot it without touching the OS volume.

Sign in to the AWS Management Console, open the EC2 service and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for step-ca. Select the SecureAnyCloud listing and choose Select, then choose Continue on the subscription summary.

Pick an instance type of t3.small or larger. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, and create or select a security group that opens port 22 from your management network and port 443 from the clients that will request certificates. Leave the root volume at the default size or larger.

Select Launch instance. First-boot initialization generates the instance's own unique certificate authority. It takes a short moment after the instance state becomes Running and the status checks pass. step-ca.service is serving its API by the time you can connect.

The following command launches an instance from the SecureAnyCloud step-ca Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing and <key-name> with your EC2 key pair name. Replace <subnet-id> with your subnet ID and <security-group-id> with a security group that opens ports 22 and 443.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type t3.small \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=step-ca}]'

When the instance reaches the Running state and passes its status checks, note its public IP address or DNS name from the EC2 console or with aws ec2 describe-instances.

Connect over SSH with your key pair and the login user for your operating system variant.

OS variant SSH login user

Ubuntu 24.04 ubuntu

ssh -i <key-name>.pem ubuntu@<public-ip>

A welcome banner lists the most useful commands. First boot writes the certificate authority details to a protected file: the per-instance CA key password, the provisioner password and the root certificate fingerprint. Read the file as follows.

sudo cat /root/step-ca-credentials.txt

Keep these values safe. The passwords are unique to this instance and are required to issue certificates and to decrypt the CA keys. Clients use the root fingerprint to bootstrap trust in your CA.

step-ca runs as a system service that is enabled and started on boot. Confirm that the daemon is active.

systemctl is-active step-ca

The command prints active. For the full unit status, including the main PID, the dedicated step user the daemon runs as and its command line, run the following.

systemctl status step-ca --no-pager

Confirm the installed binary and version. This image pins step-ca to 0.30.2.

step-ca version

The output reports step-ca 0.30.2. The matching step command-line tool is installed alongside it.

step version

step-ca serves its X.509 and ACME API over TLS on port 443. The API uses the CA's own certificate chain, which is rooted in this instance's own CA root rather than a public certificate authority. Query the health endpoint with curl -k, which skips transport verification. This is expected for a private CA. While the CA is healthy, the endpoint returns {"status":"ok"} with HTTP 200.

curl -k https://127.0.0.1/health

You can also use the step tool, which verifies the connection against the CA's own root certificate on disk.

step ca health --ca-url https://127.0.0.1 --root /etc/step-ca/certs/root_ca.crt

The command prints ok. The certificate authority is up and serving its X.509 and ACME API.

Each instance has its own unique root certificate. Inspect it to see the subject, validity and key details of your certificate authority.

step certificate inspect /etc/step-ca/certs/root_ca.crt --short

Note the root certificate fingerprint, which is also in the credentials file. Clients bootstrap trust in your CA with this fingerprint.

step certificate fingerprint /etc/step-ca/certs/root_ca.crt

To issue a short-lived leaf certificate directly from the admin provisioner, use step ca certificate. The following commands request a certificate for a private service name, signed by your CA. Supply the provisioner password from the credentials file when prompted.

step ca certificate "svc.internal" /tmp/svc.crt /tmp/svc.key \
  --provisioner admin \
  --ca-url https://127.0.0.1 \
  --root /etc/step-ca/certs/root_ca.crt step certificate inspect /tmp/svc.crt --short

The second command inspects the leaf certificate you just issued. It confirms that your CA signed the certificate and that the certificate carries the requested name.

A default ACME provisioner is also configured, so any standard ACME client (certbot, acme.sh, Caddy, Traefik and others) can request and renew certificates automatically. Point your ACME client at the CA's directory endpoint. Replace <this-host> with the address your clients use to reach the instance.

echo "https://<this-host>/acme/acme/directory"

step-ca reads its configuration from a single JSON file under STEPPATH. The configuration directory, the certificates and the keys live on the dedicated data volume.

ls /etc/step-ca/

The main configuration is config/ca.json. It defines the CA's address, the root and intermediate certificates, the database and the provisioners. Inspect it as follows.

sudo jq '.address, (.authority.provisioners[] | {type, name})' /etc/step-ca/config/ca.json

To change the CA, edit config/ca.json, or use the step ca provisioner commands to add and remove provisioners, then reload the service. You can adjust certificate lifetimes and templates, enable SSH certificates, and add JWK, OIDC, ACME or X5C provisioners. After you edit the configuration, reload step-ca to apply your changes.

sudo systemctl reload step-ca

Open port 443 to the clients that need to reach the CA in the instance security group.

The certificate authority configuration (config/ca.json), the root and intermediate certificates (certs/), the encrypted signing keys (secrets/) and the database all live on a dedicated EBS volume mounted at /etc/step-ca, which is the CA's STEPPATH. This keeps the CA material off the operating system disk and lets you resize and snapshot the volume independently. Confirm the mount.

df -h /etc/step-ca

To grow the volume, expand the EBS volume in the AWS console, then grow the filesystem on the instance with sudo resize2fs on the underlying device. To back up your certificate authority, snapshot this volume. The volume holds everything needed to restore the CA, so protect the snapshot accordingly.