How to Monitor step-ca (Smallstep Certificate Authority) with Vigilmon

step-ca from Smallstep is a production-grade private certificate authority for self-hosted infrastructure. It issues TLS certificates for your internal services, handles ACME protocol requests (so your services can auto-renew certs like they do with Let's Encrypt), runs an OCSP responder for real-time certificate revocation, and provides a full CA API for certificate lifecycle management.

When step-ca goes down, your entire PKI stops working. Services that rely on it for ACME renewal fail to renew their certificates, internal mTLS breaks down, and anything that checks OCSP for revocation status may block connections. Monitoring step-ca is as critical as monitoring your load balancer.

In this tutorial you'll set up comprehensive uptime monitoring for step-ca using Vigilmon — free tier, no credit card required.

Why step-ca downtime compounds over time

step-ca failures aren't always immediate — they compound:

ACME endpoint down — services that auto-renew via ACME start failing renewals. Certs don't expire instantly, but in 24–72 hours (depending on renewal timing), they will
OCSP responder down — clients configured with OCSP stapling or hard-fail OCSP may reject connections to services with step-ca-issued certs, even if those certs are valid
CA API unavailable — any service that requests a certificate on startup (e.g., a new pod deployment) will fail to start
CRL becomes stale — Certificate Revocation Lists have validity windows; if step-ca can't serve fresh CRLs, revocation checking breaks down

The delayed nature of ACME-related failures makes them particularly dangerous. A step-ca outage at 2am might not be noticed until 10am the next day when someone tries to deploy a new service and it fails to obtain a certificate — at which point you're scrambling to figure out the root cause of an outage that started eight hours ago.

What you'll need

A running step-ca instance (self-hosted, any recent version)
The step-ca API accessible on your monitoring network (defaults to port 9000 for HTTPS)
A free Vigilmon account — sign up takes 30 seconds

Understanding step-ca's endpoints

step-ca exposes several endpoints relevant to monitoring:

| Endpoint | What it checks | |----------|----------------| | /health | CA server liveness — returns {"status":"ok"} when alive | | /acme/{provisioner}/directory | ACME provisioner is configured and responding | | /ocsp | OCSP responder is accepting requests | | /1.0/roots | CA can serve the root certificate (useful for checking the certificate chain) |

The /health endpoint is your primary monitor. The ACME directory endpoint validates your ACME provisioner stack end-to-end.

Step 1: Verify step-ca endpoints

Before adding monitors, confirm step-ca is responding:

# CA health check (step-ca listens on HTTPS by default, port 9000)
curl -s https://ca.example.com:9000/health | jq .

# Expected output:
# {"status":"ok"}

# ACME directory (replace 'acme' with your provisioner name)
curl -s https://ca.example.com:9000/acme/acme/directory | jq .

# Expected output:
# {
#   "newNonce": "https://ca.example.com:9000/acme/acme/new-nonce",
#   "newAccount": "https://ca.example.com:9000/acme/acme/new-account",
#   "newOrder": "https://ca.example.com:9000/acme/acme/new-order",
#   ...
# }

# OCSP responder (POST a DER-encoded OCSP request)
# Basic liveness check via GET (returns method not allowed but confirms the responder is up)
curl -s -o /dev/null -w "%{http_code}" https://ca.example.com:9000/ocsp
# Returns 405 (Method Not Allowed) which confirms the responder is listening

Note: step-ca uses its own root certificate for TLS. When testing with curl, you may need to pass --cacert $(step path)/certs/root_ca.crt or use -k for testing purposes. In Vigilmon, you can configure it to skip TLS verification for self-signed roots, or better — add your step-ca root to the monitoring trust store.

Step 2: Monitor the CA health endpoint

Log in to vigilmon.online and go to Monitors → New Monitor
Choose HTTP / HTTPS as the type
Set the URL to: https://ca.example.com:9000/health
Set check interval to 1 minute
Under Expected response:
- Status code: 200
- Response body contains: "ok" (matches the {"status":"ok"} response)
If step-ca uses its own CA for its server cert, enable Skip TLS verification under advanced settings — otherwise Vigilmon's probes won't trust the cert
Save the monitor

This confirms the step-ca process is alive and the HTTP layer is responding.

Step 3: Monitor the ACME directory endpoint

The ACME directory endpoint confirms that your ACME provisioner is configured correctly and that end-to-end certificate issuance is possible. This is the most important functional test — a healthy process can still have a broken ACME provisioner if the configuration is wrong.

Create a new HTTP / HTTPS monitor
URL: https://ca.example.com:9000/acme/acme/directory
- Replace acme with your actual provisioner name (check step ca provisioner list)
Expected status code: 200
Response body contains: "newNonce" (confirms the directory object is complete)
Check interval: 1 minute
Save

If this monitor fails while the /health monitor passes, your ACME provisioner has a configuration issue — possibly a corrupt provisioner key or a missing ACME configuration block.

Step 4: Monitor the OCSP responder

The OCSP responder validates certificate revocation status in real time. Clients using OCSP hard-fail mode will reject connections to services holding step-ca certificates if the OCSP responder is unreachable.

A GET request to the OCSP endpoint returns 405 Method Not Allowed — which is actually the correct, healthy response. Add a monitor that expects this:

Create a new HTTP / HTTPS monitor
URL: https://ca.example.com:9000/ocsp
Expected status code: 405 (Method Not Allowed is the healthy response for a GET to an OCSP endpoint)
Check interval: 5 minutes (OCSP responses are cached; 5-minute checks are sufficient)
Save

This confirms the OCSP responder path is reachable and returning responses — not that it's responding correctly to OCSP protocol requests, but that it's alive and routing correctly.

Step 5: Monitor TLS certificate expiry of your CA server cert

step-ca's own server TLS certificate needs monitoring just like any other service. If step-ca uses an internally-issued cert for its HTTPS listener, that cert will typically have a shorter lifetime than a public CA cert (step-ca defaults to 24 hours for leaf certs, though you'd typically give the CA server cert a longer lifetime).

Vigilmon monitors TLS certificate expiry automatically for all HTTPS monitors. To tune the warning threshold:

Open your /health monitor settings
Under SSL certificate alerts, set the warning threshold to 30 days before expiry

A 30-day warning window gives you time to rotate the step-ca server cert before clients start rejecting connections. For step-ca, where you control the CA, cert rotation is manual unless you've set up auto-renewal via the CA itself — and having a generous warning window is especially important.

Step 6: Monitor the CA API TCP port

Add a TCP-level monitor for the step-ca port as a low-level heartbeat:

Create a new TCP Port monitor
Host: ca.example.com
Port: 9000
Check interval: 1 minute
Save

If the HTTP monitors fail but the TCP monitor passes, the port is open but the application layer has stopped responding — a sign of process hang or resource exhaustion rather than a crash.

Step 7: Configure alert channels with appropriate urgency

step-ca alerts should be routed with high priority — but not all failures warrant an immediate page. Use a tiered approach:

Critical (immediate page)

/health endpoint down for > 2 minutes
ACME directory endpoint down for > 5 minutes

High priority (alert, not immediate page)

OCSP responder down (existing certs still valid, but OCSP clients may see errors)
TLS cert expiry within 14 days

Configure this in Vigilmon:

Go to Alert Channels → Add Channel and create separate channels for your critical pager (PagerDuty, Opsgenie) and your non-urgent Slack channel
Assign the /health and ACME monitors to the critical channel
Assign the OCSP and cert expiry alerts to the high-priority Slack channel

Step 8: Diagnosing step-ca alerts

When Vigilmon fires a step-ca alert:

# 1. Check if step-ca is running
systemctl status step-ca

# 2. Check step-ca logs
journalctl -u step-ca -n 50 --no-pager

# 3. Verify the configuration file is valid
step-ca --config /etc/step-ca/config/ca.json --help

# 4. Check if the KMS or HSM is accessible
# (if using a YubiKey or Cloud KMS for the signing key)
step-kms info --kms "pkcs11:..."

# 5. Test certificate issuance manually
step ca certificate test-service test.crt test.key

# 6. Check database connectivity (step-ca uses badger or MySQL for cert storage)
# Look for database errors in logs

# 7. Verify ACME provisioner
step ca provisioner list | grep acme

Recommended monitor set for step-ca

| Monitor | Type | Alert Priority | |---------|------|----------------| | https://ca.example.com:9000/health | HTTP | Critical | | https://ca.example.com:9000/acme/acme/directory | HTTP | Critical | | https://ca.example.com:9000/ocsp | HTTP (expect 405) | High | | ca.example.com:9000 | TCP | High | | step-ca server TLS cert expiry | SSL | Warning (30 days) |

What's next

Heartbeat monitoring — if you run cert renewal cron jobs that call step ca renew, add a heartbeat monitor to confirm those jobs are completing on schedule
Certificate inventory monitoring — Vigilmon's TLS monitoring also covers all the services that receive certs from step-ca; add monitors for each internal HTTPS service to catch renewal failures before users see TLS errors
HSM/KMS availability — if step-ca is backed by a YubiKey or Cloud KMS, monitor the KMS endpoint separately; step-ca won't be able to sign certificates if the signing key is unreachable

Get started free at vigilmon.online — no credit card, monitors running in under a minute.