tutorial

Monitoring CFSSL PKI Toolkit with Vigilmon

CFSSL is CloudFlare's open source certificate authority — widely used in Kubernetes bootstrapping and internal PKI. Here's how to watch your CA's health, signing latency, and certificate expiry with Vigilmon before a silent failure locks your infrastructure out.

CFSSL is CloudFlare's open source PKI toolkit, widely used for bootstrapping Kubernetes cluster PKI, signing service mesh certificates, and running internal certificate authorities. When CFSSL is healthy, certificate issuance is invisible infrastructure. When it fails, the blast radius is enormous: new service deployments can't get TLS certs, Kubernetes kubeadm nodes can't join the cluster, and mTLS-protected services start refusing connections. Vigilmon gives you external, always-on monitoring for your CFSSL API server, signing success rates, and — critically — the CA certificate's own expiry, so you're never caught off guard by a silent CA failure.

What You'll Set Up

  • HTTP uptime monitor for the CFSSL API server health endpoint
  • Response-time monitor for the certificate signing endpoint
  • Keyword monitor confirming the CA info endpoint returns a valid response
  • SSL certificate expiry alert for the CFSSL server's own TLS certificate
  • Cron heartbeat for scheduled CA health checks and certificate audits

Prerequisites

  • CFSSL API server (cfssl serve) running and accessible
  • CFSSL health endpoint enabled (enabled by default on cfssl serve)
  • A free Vigilmon account

Step 1: Monitor the CFSSL API Server Health Endpoint

CFSSL exposes a built-in health check at /api/v1/cfssl/health. This is the fastest signal that the CA service is up and accepting requests:

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter: https://ca.yourdomain.com/api/v1/cfssl/health (or http://127.0.0.1:8888/api/v1/cfssl/health if behind a TLS-terminating proxy)
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Under Keyword check, enable Response must contain: "success":true
  7. Click Save.

The CFSSL health endpoint returns:

{"result": {"healthy": true}, "success": true}

The keyword check on "success":true ensures you catch cases where CFSSL returns a 200 but reports an unhealthy state — which can happen if the database backend is unreachable in database mode.

If CFSSL is listening only on localhost (as is common for internal PKI), set up an SSH tunnel or expose CFSSL via a TLS-terminating reverse proxy (nginx, Caddy) before adding the Vigilmon monitor. Vigilmon monitors from external IPs, so 127.0.0.1 will not be reachable without a proxy.

Step 2: Monitor the CA Info Endpoint

The /api/v1/cfssl/info endpoint returns the CA certificate in PEM format. Monitoring this endpoint confirms that CFSSL can serve CA information — a prerequisite for clients that need to download and trust your CA cert:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: https://ca.yourdomain.com/api/v1/cfssl/info
  3. Set Method to POST.
  4. Set Request body to: {}
  5. Set Request header: Content-Type: application/json
  6. Set Expected HTTP status to 200.
  7. Under Keyword check, enable Response must contain: "certificate"
  8. Set Check interval to 5 minutes.
  9. Click Save.

A failure on this endpoint indicates CFSSL cannot access the CA private key or certificate files on disk — a critical failure mode after server reboots or storage remounts.

Step 3: Monitor Certificate Signing Response Time

The /api/v1/cfssl/sign endpoint is the most operationally important: any service that needs a TLS certificate calls this endpoint. Signing latency above 500 ms can block CI/CD pipelines and slow Kubernetes pod startup. Add a response-time monitor:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: https://ca.yourdomain.com/api/v1/cfssl/sign
  3. Set Method to POST.
  4. Set Request body to a valid CSR signing request: 
    {
  "certificate_request": "-----BEGIN CERTIFICATE REQUEST-----\n...\n-----END CERTIFICATE REQUEST-----",
  "profile": "server"
}
    (Use a real CSR from your environment; see the note below on generating a test CSR.)
  5. Set Request header: Content-Type: application/json
  6. Under Response time alerts, enable Alert when p95 response time exceeds 500 ms.
  7. Set Check interval to 5 minutes.
  8. Click Save.

Generating a test CSR for monitoring:

# Generate a throwaway key and CSR for use in the Vigilmon monitor
cfssl genkey - <<'EOF' | cfssljson -bare monitor-test
{
  "hosts": ["monitor-test.local"],
  "key": {"algo": "rsa", "size": 2048},
  "names": [{"O": "Monitor Test"}]
}
EOF

# The CSR is in monitor-test.csr — base64-encode it for the JSON body:
cat monitor-test.csr

Use the raw PEM content (with \n escaped) as the certificate_request field in your Vigilmon monitor's request body. The resulting signed certificate from each monitor check is harmless — CFSSL signs it and discards the output.

Step 4: Alert on CA Certificate Expiry

The most catastrophic CFSSL failure is an expired CA certificate: all services that trusted your CA stop accepting its certificates instantly. Monitor the CA cert's expiry proactively:

  1. Open the monitor you created in Step 1 (the /api/v1/cfssl/health monitor).
  2. If CFSSL is served over HTTPS with its own certificate: enable Monitor SSL certificate and set Alert when certificate expires in less than 30 days.
  3. Click Save.

For the CA certificate itself (not the CFSSL server cert), CFSSL does not expose a built-in expiry endpoint. Use a cron heartbeat with a script that checks CA expiry:

  1. Click Add Monitor → Cron Heartbeat.
  2. Set the expected ping interval to 1440 minutes (24 hours — run the check daily).
  3. Copy the heartbeat URL: https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID.

Create a daily cron script that checks CA expiry and pings the heartbeat:

#!/bin/bash
# /etc/cron.daily/cfssl-ca-expiry-check

HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID"
CA_CERT="/etc/cfssl/ca.pem"
ALERT_DAYS=90

# Check days remaining on the CA certificate
EXPIRY=$(openssl x509 -in "$CA_CERT" -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_REMAINING=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ "$DAYS_REMAINING" -lt "$ALERT_DAYS" ]; then
  echo "WARNING: CA certificate expires in ${DAYS_REMAINING} days" >&2
  # Do NOT ping the heartbeat — the missed heartbeat triggers the Vigilmon alert
  exit 1
fi

# CA cert is healthy — ping the heartbeat to signal the check passed
curl -s "$HEARTBEAT_URL" > /dev/null

Make it executable and install it:

chmod +x /etc/cron.daily/cfssl-ca-expiry-check

If the CA cert is within 90 days of expiry, the script exits without pinging Vigilmon. The missed heartbeat triggers an alert to your team. This gives you a 90-day runway to rotate the CA — a lengthy process in any infrastructure.

Step 5: Monitor the CFSSL Server's TLS Certificate

If your CFSSL API server is accessible over HTTPS (recommended for any externally-accessible CA), its own TLS certificate must not expire. This is an easy self-referential failure point — a CA whose server cert has lapsed:

  1. Open the HTTP monitor from Step 1.
  2. Enable Monitor SSL certificate.
  3. Set Alert when certificate expires in less than 30 days.
  4. Click Save.

For CAs running in air-gapped or internal-only environments behind an nginx proxy, add the SSL monitor on the proxy's domain:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: https://ca.yourdomain.com (the nginx proxy hostname).
  3. Enable Monitor SSL certificate with a 30 days alert.
  4. Click Save.

Step 6: Configure Alert Channels and Escalation

  1. Go to Alert Channels in Vigilmon and add Slack, PagerDuty, or email. For a CA used in Kubernetes bootstrapping, use PagerDuty or a paging-capable channel — CA outages block pod scheduling.
  2. Set Consecutive failures before alert to 1 on the signing endpoint monitor — a single signing failure in a CI/CD pipeline is already a breaking failure.
  3. Set Consecutive failures before alert to 2 on the health endpoint monitor to absorb transient network blips.
  4. For the CA expiry heartbeat, set Grace period to 60 minutes to allow for occasional cron timing drift.

For teams using CFSSL in Kubernetes cluster bootstrapping, add a maintenance window during cluster upgrades:

curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "YOUR_MONITOR_ID", "duration_minutes": 30}'

Summary

| Monitor | Target | Alert Threshold | What It Catches | |---|---|---|---| | Health endpoint | /api/v1/cfssl/health | Non-200 or missing "success":true | CA service down | | CA info endpoint | /api/v1/cfssl/info | Non-200 or missing "certificate" | CA key/cert unreadable | | Signing latency | /api/v1/cfssl/sign | p95 > 500 ms | Signing bottleneck | | CFSSL server TLS | CFSSL HTTPS domain | Expiry < 30 days | CA server cert expired | | CA cert expiry | Daily cron heartbeat | Missed heartbeat | CA cert expiring within 90 days |

CFSSL is quiet when healthy and catastrophic when it fails. A CA outage doesn't just break one service — it blocks every workload that needs to prove its identity with a TLS certificate. Vigilmon's external monitoring ensures your team has advance warning before an expired CA cert, a crashed signing process, or a lost private key file turns into a multi-hour infrastructure incident.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles