Your Own Certificate Authority, Without the Headache

If you've ever tried to stand up a public key infrastructure (PKI) for your team, you know it's a project that usually gets postponed forever. Between managing root certificates, intermediate CAs, and figuring out how to issue certs to your Kubernetes pods without a full-time security engineer, it's a lot. What if you could just run a single binary and get a working online CA that handles HTTPS, SSH, and ACME automatically? That's exactly what step-ca aims to deliver.

step-ca is an open-source, online certificate authority built for DevOps workflows. It's the server-side counterpart to the step CLI tool, and together they form a complete toolkit for managing certificates and keys. Think of it as the CA you can actually operate without needing a dedicated PKI team.

What It Does

At its core, step-ca issues certificates. But it's the kind of certificates and the way it issues them that makes it interesting. It's an online CA, meaning it runs as a service and responds to certificate requests in real time, rather than being an offline, manually-operated signing authority.

The project is written in Go and supports a few key use cases:

• HTTPS certificates: It can issue server and client certificates that are compliant with RFC5280 and the CA/Browser Forum baseline requirements. That means you can get certificates that actually work in browsers, not just internally.
• DevOps TLS certificates: For VMs, containers, APIs, database connections, and Kubernetes pods. This is where the automation angle comes in.
• SSH certificates: For people (in exchange for single sign-on identity tokens) and for hosts (in exchange for cloud instance identity documents). This replaces the old model of distributing SSH keys manually.

The automation story is strong. step-ca is an ACME server, so it supports all the popular ACME challenge types you'd expect from something like Let's Encrypt. That means your existing tooling that speaks ACME can talk to it. There's also a Go wrapper library for programmatic access, and the step CLI tool for scripting.

Why It's Cool

The most compelling thing about step-ca is that it removes the barrier to entry for running your own CA. Small teams often skip PKI entirely because the setup cost is too high. This project makes it a realistic option.

Here's what stands out:

• Short-lived certificates are the default mindset: The README explicitly calls out support for choosing key types (RSA, ECDSA, EdDSA) and lifetimes. Short-lived certs are a security best practice—they limit the blast radius if a key leaks—but they only work if you have automation to renew them. step-ca is built for that workflow.
• It speaks the protocols you already use: Being an ACME server is huge. You don't need to learn a proprietary API to get certificates. If you've used Let's Encrypt, you already understand the enrollment flow.
• One tool for HTTPS and SSH: Most teams treat these as separate problems. step-ca unifies them, letting you manage both your web PKI and your SSH infrastructure from the same authority.
• Honest about its limits: I appreciate that the README clearly delineates what the open-source project does well (two-tier PKI for common DevOps use cases) and what it doesn't do (active revocation via CRL/OCSP, multi-CA setups, FIPS compliance). Those features exist in their commercial product, and the comparison is transparent. That's refreshing.

The practical benefit here is real. If you're tired of certificate expiry incidents or manually scp'ing SSH keys around, this tool gives you a path to automate all of it.

How to Try It

Getting started is straightforward. The project is hosted at github.com/smallstep/certificates, and you'll want to pair it with the step CLI tool from github.com/smallstep/cli.

1. Install the step CLI: This is your client for bootstrapping and managing the CA. Installation instructions are on the Smallstep docs site.
2. Initialize your CA: Run step ca init to generate your root and intermediate keys and certificates. You'll pick a name for your CA and choose your key type.
3. Start the server: Run step-ca with the config file that was generated during initialization.
4. Get a certificate: Use the step ca certificate command to request a cert, or configure your ACME client to point at your new CA.

For Go developers, you can also use the client wrapper directly in your applications. The repo has examples showing basic client usage. If you're integrating certificate issuance into your own Go services, that's the path you'll want to explore.

One thing to note: if you need to revoke certificates actively (using CRL or OCSP) or you need multiple CAs, the open-source version won't cover you. The README points to their commercial offering for those cases. But for a two-tier PKI serving standard DevOps needs, this is a solid starting point.

Final Thoughts

step-ca is one of those tools that makes you wonder why this wasn't the standard approach all along. It's practical, well-documented, and it meets you where you are—whether that's ACME, the step CLI, or a Go library. If you've been putting off PKI because it seemed too heavy, this is worth a weekend experiment. It won't solve every certificate problem in the enterprise world, but for a modern DevOps setup with containers, Kubernetes, and SSH, it might be exactly the missing piece.

Follow @githubprojects for more developer tools and open source projects.