Running your own on-prem PKI (Public Key Infrastructure) can be a game-changer and it’s not just for enterprises, but also for advanced homelabs. Whether it’s about securing internal services, managing client certificates for S/MIME email encryption, or just having full control over certificate issuance, operating your own root CA brings a lot of flexibility and independence. There are many ways to set up a basic CA, even just using OpenSSL on the command line. But as soon as your setup grows, you’ll quickly run into limitations. Things like revoking certificates, publishing CRLs, using OCSP, or automating issuance via the ACME protocol become essential. And that’s where more powerful tools come in. Popular solutions like FreeIPA, HashiCorp Vault, or EJBCA offer robust PKI functionality, but they can be overkill for some environments or tricky to integrate with specific workflows. One tool that’s gained a lot of traction in recent years is Step-CA, an open-source CA by Smallstep. It’s lightweight, modern, and supports ACME out-of-the-box making it a great fit for both homelab users and smaller enterprise setups. I’ve often been asked how to simplify certificate management for Proxmox VE nodes. That’s why in this post, we’ll walk through the setup of an own root CA using Step-CA on a Debian-based system. We’ll cover the initial installation, configuration, and enabling of ACME services. Beside this, step-ca also support many other provisioner. Afterwards, we’ll issue and revoke certificates manually to get a feel for how the CA works. Finally, we’ll integrate it with a Proxmox node using the ACME protocol to make certificate renewal fully automatic. By the end of this guide, you’ll have a fully functional PKI of your own where your nodes will be talking TLS with certificates issued straight from your own infrastructure.
Step-CA & Step-CLI
When working with Step-CA, you’ll quickly come across two main components: step-ca and step (often referred to as step-cli). They belong together but serve different purposes and therefore it’s important to understand when and why you need each. step-ca is the actual certificate authority server which is the service that runs in the background, handles requests, issues certificates, checks identities, and provides features like ACME, CRLs, and OCSP. If you’re running your own PKI infrastructure, step-ca is the core component that stays online and does the heavy lifting. On the other hand, step is the command-line tool(cli) used to interact with the CA. It’s like a Swiss Army knife for certificate management: you use it to request certificates, generate key pairs, bootstrap new CAs, create tokens, and even test ACME endpoints. Especially during setup and configuration, the CLI is essential. It simplifies a lot of the complex OpenSSL steps and makes working with certificates way more approachable. A good example: if you’re creating a new root certificate, you’ll do that with step. Later, when a Proxmox node automatically requests a cert via ACME, it’s the step-ca server handling that request behind the scenes.
Installation on Debian
To get started with your own PKI infrastructure, the first step is setting up a clean and dedicated system where your certificate authority will run. In this guide, we’re using a Debian-based system. In general, this also works fine on any other Distribution but it’s up to you to get the packages. Within this approach, the idea is to isolate the PKI from your other services so that it remains secure, stable, and easier to manage. Step-CA and the Step CLI are provided by Smallstep and can be installed quickly using their official packages. As said before, it consists of two packages which we’re now installing by running the following commands:
apt-get update
apt-get install -y wget
wget https://dl.step.sm/gh-release/cli/docs-ca-install/v0.23.1/step-cli_0.23.1_amd64.deb
wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.23.1/step-ca_0.23.1_amd64.deb
dpkg -i step-cli_0.23.1_amd64.deb
dpkg -i step-ca_0.23.1_amd64.deb
During the installation you will be asked which kind of installation method you like to use:
? What deployment type would you like to configure?:
▸ Standalone - step-ca instance you run yourself
For our on-prem installation we use the Standalone mode. Afterwards, everything is in place and we can move over to initialize our root CA.
Initializing the Root-CA
The heart of your PKI is our own Certificate Authority (CA). It’s what you’ll use to issue and sign certificates and everything that trusts your root certificate will automatically trust any certificates issued by it. That’s why setting it up cleanly and securely is so important.
To initialize your new CA, we just run the following in your terminal:
step ca init
This interactive command guides you through the setup process where you’ll be asked to enter a name for your CA (something like “gyptazy.com open-source solutions”) and define how it should be reachable (via DNS names or IPs), and choose where your root and intermediate certificates will be stored.
Important: When specifying the DNS names during setup, make sure you enter exactly how your CA will be accessed, both internally and externally. This includes hostnames like ca01.gyptazy.com for internal connections or external hostnames like ca.gyptazy.com. These values are embedded in the certificate and become critical when using ACME later. If the hostname a client connects to doesn’t match the certificate, the connection will fail and especially for systems that enforce strict TLS verification (like Proxmox or browsers).
The step ca init command will also set up your root CA and an intermediate CA. This is a good practice: the root stays offline and rarely used, while the intermediate does the actual signing work. Once the init process is finished, you’ll have a full CA hierarchy ready to go which is stored securely on your system and ready for the next step: starting the step-ca service.
Starting the Step-CA Server
While managing the CA can be done with the cli tool, the step-ca server serves the required components to fulfill the requests. Therefore, we need to start the server. In the easiest way this can also be done on the cli by running the following command:
step-ca $(step path)/config/ca.json
Afterwards, we can validate that the service is up and running:
step ca health
Note: You might want to create a systemd unit file to start the service automatically on system start. Adding ACME Support to Step-CA
Enabling ACME in Step-CA is as simple as running:
step ca provisioner add acme --type ACME
To customize certificate duration:
step ca provisioner update acme \
--x509-min-dur=20m \
--x509-max-dur=72h \
--x509-default-dur=36h
Basic Certificate Management
Create a certificate:
step ca certificate test01.gyptazy.com test01.crt test01.key
Revoke a certificate:
# Certificate File
step ca revoke --crt test01.crt
# Certificate Serial
step ca revoke --serial
Proxmox using Step-CA with ACME
Register your custom ACME provider:
pvenode acme account register default contact@gyptazy.com \
--directory https://ca.gyptazy.com/acme/acme/directory
Once registered, your Proxmox node can request certificates automatically through your Step-CA ACME server.
Conclusion
Running your own PKI with Step-CA gives you full control over certificate management. From manually issuing and revoking certificates to fully automating the process using the ACME protocol. With ACME support enabled, modern systems like Proxmox can automatically request and renew certificates just like they would with Let’s Encrypt but within your own trusted infrastructure. This setup is not only ideal for enterprise environments that need strict internal security and compliance, but it’s also a powerful solution for homelab enthusiasts who want to avoid external dependencies and build a reliable, self-contained ecosystem. And just like this post showcases, it’s not too difficult to set up and maintain. A step closer to a secure and de-centralized environment!