tutorial

Monitoring EJBCA Enterprise PKI with Vigilmon

EJBCA is the leading open source certificate authority platform — here's how to monitor its CA application, OCSP responder, CRL freshness, HSM availability, certificate expiry, and audit log integrity with Vigilmon.

EJBCA (Enterprise Java Beans Certificate Authority) is the most feature-complete open source PKI platform available — supporting X.509 certificate issuance, OCSP revocation checking, CRL distribution, ACME automation, SCEP, CMP, EST, and a Timestamp Authority in a single deployable Java EE application. Organizations running EJBCA in production — for industrial IoT device identity, healthcare PKI, government CA infrastructure, or enterprise TLS certificate management — depend on its continuous availability: certificate issuance failures block device onboarding, OCSP outages cause TLS handshake failures across dependent services, and an expired CA certificate can take an entire PKI hierarchy offline. Vigilmon gives your EJBCA deployment independent external monitoring across every critical PKI function.

What You'll Set Up

  • HTTP health monitor for the EJBCA application server (WildFly/JBoss)
  • OCSP responder health and latency monitor
  • CRL freshness heartbeat
  • CA certificate expiry alerts
  • HSM slot availability monitor
  • Database connectivity monitor
  • ACME endpoint health monitor
  • Audit log integrity heartbeat
  • Alert thresholds calibrated for PKI criticality

Prerequisites

  • EJBCA 7.x or later deployed on WildFly or JBoss AS
  • An OCSP responder endpoint published and accessible
  • CRL distribution points (CDPs) configured per CA
  • A relational database (MariaDB, MySQL, or PostgreSQL) for EJBCA persistence
  • A free Vigilmon account

Step 1: Monitor the EJBCA Application Health Endpoint

EJBCA exposes a built-in health check endpoint that validates the application server, database connection, and HSM accessibility in a single request. This is the most important monitor to set up first.

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. URL: https://ca.yourdomain.com/ejbca/publicweb/healthcheck/ejbcahealth.
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Under Keyword check, enter ALLOK — the EJBCA health endpoint returns ALLOK when all components are healthy.
  7. Enable Monitor SSL certificate and set the expiry alert threshold to 30 days (PKI hosts should have longer lead times than typical web services).
  8. Click Save.

Any response other than 200 ALLOK — including partial health failures listed in the response body — indicates a component has failed. EJBCA's health endpoint is designed exactly for this use case, so trust it as a first-line signal for the entire CA stack.

Step 2: Monitor the OCSP Responder

The OCSP responder provides real-time certificate status to TLS clients checking revocation. OCSP outages cause handshake failures in strict-mode clients (browsers with hard-fail OCSP, mobile applications with certificate pinning, and enterprise PKI clients).

Monitor OCSP endpoint availability:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: https://ca.yourdomain.com/ejbca/publicweb/status/ocsp (or your OCSP responder URL as published in AIA extensions).
  3. Check interval: 1 minute
  4. Expected HTTP status: 200
  5. Click Save.

Test OCSP response correctness with a heartbeat:

For production environments, validate that the OCSP responder returns a syntactically valid response using openssl:

  1. Click Add Monitor → Cron Heartbeat.
  2. Set the expected interval to 5 minutes.
  3. Copy the heartbeat URL.
  4. Create a script:
#!/bin/bash
# /usr/local/bin/check-ocsp.sh
OCSP_URL="http://ca.yourdomain.com/ejbca/publicweb/status/ocsp"
CERT_FILE="/etc/ssl/certs/issued-cert.pem"
CA_CERT="/etc/ssl/certs/ca-cert.pem"

RESPONSE=$(openssl ocsp \
  -issuer "$CA_CERT" \
  -cert "$CERT_FILE" \
  -url "$OCSP_URL" \
  -text 2>&1)

if echo "$RESPONSE" | grep -q "Response verify OK"; then
  curl -sf "https://vigilmon.online/heartbeat/your-ocsp-heartbeat-id" > /dev/null
fi

*/5 * * * * /usr/local/bin/check-ocsp.sh

Step 3: Monitor CRL Freshness

Certificate Revocation Lists must be published before their nextUpdate time. Stale CRLs cause revocation validation failures in strict CRL clients and violate CA/Browser Forum requirements for publicly trusted CAs.

  1. Click Add Monitor → Cron Heartbeat.
  2. Set the expected interval to 60 minutes (adjust based on your CRL issuance schedule — typically 24 hours, but the check itself should run hourly to catch delays early).
  3. Copy the heartbeat URL.
  4. Create a CRL freshness check script:
#!/bin/bash
# /usr/local/bin/check-crl-freshness.sh
CRL_URL="http://ca.yourdomain.com/ejbca/publicweb/webdist/certdist?cmd=crl&issuer=CN%3DIssuingCA"

# Download CRL and check nextUpdate
CRL_NEXT=$(curl -sf "$CRL_URL" | \
  openssl crl -inform DER -noout -nextupdate 2>/dev/null | \
  awk '{print $NF}')

if [ -z "$CRL_NEXT" ]; then
  echo "CRL download failed" >&2
  exit 1
fi

# Convert to epoch and compare
CRL_EPOCH=$(date -d "$CRL_NEXT" +%s 2>/dev/null || \
            date -j -f "%b %d %T %Y %Z" "$CRL_NEXT" +%s 2>/dev/null)
NOW_EPOCH=$(date +%s)

# Alert if CRL expires within 2 hours
if [ $((CRL_EPOCH - NOW_EPOCH)) -gt 7200 ]; then
  curl -sf "https://vigilmon.online/heartbeat/your-crl-heartbeat-id" > /dev/null
fi

0 * * * * /usr/local/bin/check-crl-freshness.sh

When a CRL is not renewed before its nextUpdate, this heartbeat stops pinging and Vigilmon alerts you — giving you time to investigate CRL signing failures before clients begin rejecting the stale CRL.

Step 4: Monitor CA Certificate Expiry

CA certificates have long validity periods but their expiry is catastrophic — an expired CA certificate makes every certificate issued under it invalid immediately, breaking all dependent TLS connections. Monitor CA certificate expiry with long lead times.

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: https://ca.yourdomain.com/ejbca/publicweb/webdist/certdist?cmd=cacert&issuer=CN%3DIssuingCA&level=0 (the CA certificate download endpoint).
  3. Check interval: 60 minutes
  4. Expected HTTP status: 200
  5. Click Save.

Then add a dedicated certificate expiry check via heartbeat for deeper monitoring:

#!/bin/bash
# /usr/local/bin/check-ca-cert-expiry.sh
CA_CERT_URL="https://ca.yourdomain.com/ejbca/publicweb/webdist/certdist?cmd=cacert&issuer=CN%3DIssuingCA&level=0"

DAYS_LEFT=$(curl -sf "$CA_CERT_URL" | \
  openssl x509 -inform DER -noout -enddate 2>/dev/null | \
  awk -F= '{print $2}' | \
  xargs -I{} bash -c 'echo $(( ($(date -d "{}" +%s) - $(date +%s)) / 86400 ))')

# Alert when CA cert has fewer than 90 days remaining
if [ -n "$DAYS_LEFT" ] && [ "$DAYS_LEFT" -gt 90 ]; then
  curl -sf "https://vigilmon.online/heartbeat/your-ca-expiry-heartbeat-id" > /dev/null
fi

A 90-day lead time for CA certificate renewal allows for proper CA ceremony planning, HSM coordination, and cross-signing if required.

Step 5: Monitor HSM Availability

EJBCA stores CA private keys inside HSMs (Hardware Security Modules). If the HSM becomes unreachable, EJBCA cannot sign certificates, CRLs, or OCSP responses — the CA is operationally dead even though the application server is healthy.

Monitor the HSM network port (if network-attached):

  1. Click Add Monitor → TCP Port.
  2. Host: your-hsm-host
  3. Port: 1500 (nCipher/Thales nShield default) or the port for your HSM model
  4. Check interval: 1 minute
  5. Click Save.

Monitor HSM slot accessibility via EJBCA health endpoint:

The EJBCA health endpoint already checks HSM slot accessibility as part of its ALLOK response (Step 1). If HSM becomes unavailable, the health endpoint returns a detailed error including the affected crypto token, so your Step 1 monitor catches this automatically. Add the TCP port monitor as an independent lower-level signal.

Step 6: Monitor the Database

EJBCA stores all certificates, CRL data, certificate profiles, CA configurations, end entity records, and audit log entries in a relational database. Database loss makes EJBCA unable to issue certificates, check revocation state, or write audit entries.

For MariaDB/MySQL:

  1. Click Add Monitor → TCP Port.
  2. Host: localhost (or your DB host)
  3. Port: 3306
  4. Check interval: 1 minute
  5. Click Save.

For PostgreSQL:

  1. Click Add Monitor → TCP Port.
  2. Host: localhost
  3. Port: 5432
  4. Check interval: 1 minute
  5. Click Save.

Step 7: Monitor ACME Endpoint Health

EJBCA's ACME endpoint implements the Let's Encrypt protocol for automated certificate renewal. Services that use ACME for certificate management (including internal services using EJBCA as a private ACME CA) will fail to renew when this endpoint is unavailable.

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: https://ca.yourdomain.com/ejbca/acme/directory (the ACME directory endpoint — publicly accessible and returns a JSON metadata document without authentication).
  3. Check interval: 2 minutes
  4. Expected HTTP status: 200
  5. Under Keyword check, enter newNonce — the ACME directory JSON always contains this key when the endpoint is functional.
  6. Click Save.

An unhealthy ACME directory endpoint causes certificate renewal failures across any service configured to use this ACME CA — typically surfacing as certificate expiry alerts in dependent services days later without a clear root cause.

Step 8: Monitor Audit Log Integrity via Heartbeat

EJBCA maintains an immutable audit log for all CA operations — certificate issuance, revocation, admin access, and key operations. Audit log write failures indicate a security control failure and may violate compliance requirements (Common Criteria, WebTrust for CAs).

  1. Click Add Monitor → Cron Heartbeat.
  2. Set the expected interval to 15 minutes.
  3. Copy the heartbeat URL.
  4. Create a script that queries EJBCA's audit log API and verifies recent entries are present:
#!/bin/bash
# /usr/local/bin/check-ejbca-auditlog.sh
# Requires EJBCA admin REST API access
EJBCA_BASE="https://ca.yourdomain.com/ejbca/ejbca-rest-api/v1"
API_CLIENT_CERT="/etc/ejbca/admin-client.pem"
API_CLIENT_KEY="/etc/ejbca/admin-client.key"

RESULT=$(curl -sf \
  --cert "$API_CLIENT_CERT" \
  --key "$API_CLIENT_KEY" \
  "$EJBCA_BASE/audit/search" \
  -H "Content-Type: application/json" \
  -d '{"max_number_of_results": 1}' \
  2>/dev/null)

if echo "$RESULT" | grep -q "timestamp"; then
  curl -sf "https://vigilmon.online/heartbeat/your-auditlog-heartbeat-id" > /dev/null
fi

*/15 * * * * /usr/local/bin/check-ejbca-auditlog.sh

Step 9: Configure Alert Channels and Thresholds

  1. Go to Alert Channels in Vigilmon and add Slack, email, or a PagerDuty/OpsGenie webhook.
  2. For the EJBCA health endpoint, set Consecutive failures before alert to 1 — PKI downtime is immediately operational and potentially compliance-impacting.
  3. For the OCSP HTTP monitor, set to 1 — OCSP outages cause TLS handshake failures in dependent services within seconds.
  4. For the HSM TCP monitor, set to 1 — HSM loss means the CA cannot sign anything.
  5. For the database TCP monitors, set to 1 — database loss is a complete PKI failure.
  6. For the CRL freshness heartbeat and ACME endpoint, set to the default heartbeat expiry window.
  7. Route CA certificate expiry alerts to your PKI operations team directly — these require CA ceremony planning, not just a ticket.

Summary

| Monitor | Target | What It Catches | |---|---|---| | EJBCA health endpoint | /ejbca/publicweb/healthcheck/ejbcahealth | Application, DB, and HSM failure | | OCSP HTTP | OCSP responder URL | Revocation service unavailable | | OCSP validity heartbeat | openssl ocsp check | Invalid or unsigned OCSP responses | | CRL freshness heartbeat | CRL download + nextUpdate check | Stale CRL before clients reject it | | CA cert expiry heartbeat | CA cert download check | <90 days to CA cert expiry | | HSM TCP port | HSM network port | HSM network unreachable | | Database TCP | :3306 / :5432 | Database connectivity loss | | ACME directory | /ejbca/acme/directory | ACME renewal endpoint failure | | Audit log heartbeat | Audit REST API | Audit log write failure |

EJBCA is the backbone of your organization's identity infrastructure — device certificates, TLS, code signing, and authentication all flow through it. With Vigilmon monitoring the full stack — application health, OCSP responder, CRL freshness, CA certificate expiry, HSM connectivity, and audit log integrity — you catch PKI failures in seconds, not when a cascade of expired certificates or blocked TLS handshakes finally surfaces in your application monitoring.

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