ReactorCA: Finally, a TLS Certificate Authority That Doesn't Suck for Homelabs

I’ll be honest — every time I open my browser to check on my NAS, Proxmox cluster, or Home Assistant instance, that red “Your connection is not private” warning drives me up the wall. I know I can click “Advanced” and proceed. I know it’s “fine.” But doing it dozens of times a week? It gets old fast.

Let’s Encrypt won’t work for internal domains. Buying commercial certs for a homelab is absurd. So I’ve been hunting for a “personal CA” solution — something that can issue certificates for my LAN devices without making my browser freak out.

That’s how I stumbled upon ReactorCA, a Go-based CLI tool with 124 GitHub stars. It’s niche, it’s small, but it solves exactly this problem.

What Problem Does It Actually Solve?

ReactorCA is built for one thing: managing a small Certificate Authority for homelabs and SOHO environments. Its core philosophy is “inversion of control” — unlike traditional CAs where clients generate CSRs, ReactorCA manages all private keys centrally. One command to issue, one command to renew, one command to deploy.

The author’s motivation is timely too. Apple already limits certificate lifetimes to one year, and the industry is marching toward 47-day validity by 2029. Manual certificate management is becoming unsustainable. Automation isn’t a nice-to-have anymore — it’s mandatory.

Core Features Breakdown

1. Self-Signed CA Creation and Management

The basics: create a root CA that you trust once, and every certificate it signs becomes trusted too.

ca init          # Initialize config files, auto-detect SSH keys
ca ca create     # Generate a self-signed CA (password-protected)

Configuration lives in config/ca.yaml — validity (default 10 years), key algorithm (RSA 2048-4096, EC P256-521, ED25519), hash algorithm (SHA256/384/512), and your encryption provider of choice.

2. Host Certificate Issuance and Renewal

Issue certificates for specific hosts with full SAN support — DNS names, IP addresses, emails, URIs.

ca host issue my-nas      # Issue a cert for my-nas
ca host list              # View all certs with expiration dates
ca host issue my-nas --deploy  # Issue and deploy in one shot

Per-host configs go in config/hosts.yaml. Each host gets its own validity period, crypto settings, export paths, and deployment commands. Variable substitution includes ${cert}, ${chain}, ${key_encrypted}, and ${private_key} — handy for writing deployment scripts.

3. Multiple Private Key Encryption Options

This is where ReactorCA really shines. Private keys are encrypted with age’s ChaCha20-Poly1305, and you get three ways to unlock them:

Password: scrypt key derivation, works everywhere
SSH key: Supports Ed25519, RSA, and ECDSA — convenient if you already have SSH keys set up
Hardware tokens: YubiKey, Apple Secure Enclave, TPM via age plugins

I’m using password mode myself, but the YubiKey support genuinely impressed me. You don’t see hardware token integration in homelab tools very often.

4. Automated Deployment

After issuing a certificate, deploy it via shell scripts to target devices. The author includes examples for FritzBox, Proxmox PVE, and NixOS.

# config/hosts.yaml example
my-nas:
  sans:
    dns: [nas.local, nas.lan]
    ip: [192.168.1.10]
  validity: 365d
  export:
    cert: /tmp/nas.crt
    key: /tmp/nas.key
  deploy:
    - scp ${cert} ${key} root@nas:/etc/nginx/ssl/
    - ssh root@nas "systemctl restart nginx"

5. Certificate Inventory and Expiration Tracking

ca host list shows all certificates and their expiration dates. There’s no auto-renewal daemon, but at least you can see what’s about to expire at a glance.

The store layout is refreshingly clean:

store/
├── ca/ca.crt, ca.key.age
├── hosts/<id>/cert.crt, cert.key.age
└── ca.log

Real-World Use Cases

After testing it out, here are the scenarios where ReactorCA really clicks:

Unified internal certificate management: NAS, router admin panels, Proxmox, Home Assistant — all signed by one CA. Import the root cert once, green locks everywhere.

VPN internal certificates: WireGuard or Tailscale networks where internal hostnames need valid TLS. ReactorCA handles the whole fleet.

Git-driven certificate infrastructure: Everything is YAML. The store directory can live in git. Certificate changes go through PRs. Team-friendly and auditable.

Quick Start

Installation is dead simple — grab a prebuilt binary or compile from source:

go build -o ca ./cmd/ca

Then it’s a four-step dance:

ca init
ca ca create
ca host issue <host-id>
ca host deploy <host-id>

Takes under five minutes. Honestly smoother than I expected.

The Good and The Bad (And Yes, There Is Bad)

Pros:

Single static binary, zero runtime dependencies — classic Go
Age-encrypted private keys, way more secure than plaintext PEM files
Hardware token support — YubiKey users will love this
Configuration-as-code, Git-friendly
Flexible deployment scripts with variable substitution

Cons:

No intermediate CA support: You get one root CA, period. Can’t do hierarchical PKI. If your homelab is complex and you want regional or functional CA splits, tough luck.
No CRL or OCSP: Certificate revocation is basically manual deletion. No standard revocation mechanism. If a private key gets compromised, you just hope nobody’s using it.
No PKCS#12 export: Some devices (older Windows IIS, certain network gear) only accept p12 format. You’ll need to convert with openssl yourself.
No auto-renewal daemon: The author touts “one-button reissue,” but you still need to run commands manually or set up your own cron job. Given the “47-day validity” motivation, the lack of automatic renewal is a real gap.
ED25519 compatibility warning: The author themselves note it’s “not recommended for general public use in 2025.” For homelab internals it doesn’t matter, but RSA2048+SHA256 is the safe bet if you’re going broader.
124 stars = tiny community: Don’t expect Stack Overflow answers. If you hit an edge case, you’re reading source code or filing an issue.

Comparison with Alternatives

Tool	Strengths	Best For
ReactorCA	Lightweight CLI, age encryption, Git-friendly	Homelab / small office, simplicity-first
Let’s Encrypt	Free public certs, auto-renewal	Public domains with port 80/443 access
step-ca	Full-featured, intermediate CAs, ACME protocol	Enterprise or teams needing complete PKI
XCA	GUI interface, visual management	Users who prefer clicking over typing
certstrap	Minimal, Netflix-backed	Quick dev/test certificate generation
EasyRSA	OpenVPN companion tool	Primarily VPN certificate setups

Let’s Encrypt is the gold standard for free certs, but it doesn’t work for internal domains. step-ca is far more capable — ACME protocol, intermediate CAs, the works — but it’s also heavier to deploy and configure. ReactorCA sits in a sweet spot: more features than certstrap, lighter than step-ca.

Who Should Use This?

ReactorCA is worth a look if you:

Run multiple internal services and are tired of browser security warnings
Want a Git-friendly certificate management workflow
Care about private key security and don’t want plaintext PEM files lying around
Own a YubiKey or similar hardware token and want to actually use it
Don’t want to deploy a full step-ca just for a handful of homelab certs

But if you need enterprise PKI features — intermediate CAs, auto-renewal, revocation lists, multi-tenancy — look at step-ca or commercial solutions instead.

Final Thoughts

ReactorCA is a “just right” tool. It won’t solve every certificate problem under the sun, but for homelabs and small offices, it covers the essentials well. The age encryption for private keys is a standout feature, and the Git-driven configuration approach feels natural for developers.

That said, it’s a 124-star project. Don’t expect Let’s Encrypt levels of maturity and stability. My take: perfect for personal homelabs, workable for small teams, but tread carefully in production environments.

Rating: ⭐⭐⭐⭐ (deducting one star for missing auto-renewal and CRL support)