Axelspire

Certificate Observability Strategy: Beyond Expiry Alerts

If you ask most organisations what certificate monitoring means, the answer is some variation of "we get alerts when certificates are about to expire." That's a valid metric. It's also the minimum viable version of observability — and for organisations managing thousands of certificates across multiple CAs, environments, and teams, it's nowhere near sufficient.

Expiry is one signal; mature operations also track issuance failures, CA latency, policy drift, and configuration mismatch.
Expiry is one signal; mature operations also track issuance failures, CA latency, policy drift, and configuration mismatch.

Expiry monitoring catches one failure mode: the clock runs out. It doesn't catch the certificate that renewed successfully but with the wrong key size. It doesn't catch the CA that's responding 30% slower this month. It doesn't catch the team that deployed a self-signed certificate in production because their Issuer was misconfigured. It doesn't catch the certificate that's valid but doesn't match the configuration in the load balancer.

Certificate observability is the practice of instrumenting your certificate estate to understand its health, compliance, and operational behaviour — not just its countdown timers. The progression from monitoring to observability to intelligence is the progression from reactive to diagnostic to predictive. Most organisations are stuck at reactive.

Featured Tool Runs fully in-browser

PKI Health Radar

Drag the sliders to assess your current posture — scores update instantly.

6 more tools: Cost & Risk Explorer Timeline Builder Shadow Heatmap Process Transform Slider Scenario Comparator What-If Demo All tools & guide →

The Certificate SLO Framework

Service Level Objectives for certificates might sound like overengineering, but consider the alternative: you have no defined standard for what "good" looks like in your certificate operations, so you only notice problems when they cause outages.

A certificate SLO framework defines measurable targets across five dimensions.

Issuance success rate. What percentage of certificate requests complete successfully on the first attempt? Target: >99.5%. Sustained rates below this indicate CA integration issues, validation failures, or misconfigured automation. Track per CA and per environment to isolate which integration path is degraded.

Mean time to renewal (MTTR). How long does it take from renewal trigger to certificate deployment? For automated ACME-based renewal, this should be minutes. For manual processes, days. Track the distribution, not just the mean — a handful of certificates taking weeks to renew can hide behind a healthy average. As certificate lifetimes shrink toward 47 days, MTTR becomes a tighter constraint. A renewal process that takes 5 days is fine with 398-day certificates. At 47-day lifetimes, 5 days is 10% of the certificate's life.

Policy compliance rate. What percentage of active certificates conform to your organisation's certificate policy — key size, algorithm, CA source, naming conventions, lifetime? Track deviations, not just violations. A certificate with a 2048-bit RSA key in an environment that requires 4096-bit isn't necessarily broken, but it's a drift indicator.

Configuration consistency. Does the deployed certificate match what was issued? Does the certificate in the load balancer match the one in the origin server? Are certificate chains complete? Configuration drift is the silent killer of TLS reliability — the certificate is valid, the deployment is wrong, and the outage happens at the worst possible time.

CA response time. How fast are your CAs responding to issuance and validation requests? Track separately for each CA in your multi-CA architecture. A CA that's meeting SLAs today but trending slower over months is a leading indicator of capacity problems that will eventually affect your renewal operations.

Certificate Risk Scoring

Not all certificates are equal. A wildcard certificate protecting your primary customer-facing domain carries more operational risk than a single-domain certificate on an internal staging server. A certificate issued from a CA that was recently distrusted carries more risk than one from a stable CA. A certificate that expires in 48 hours with no automation configured carries more risk than one expiring in 200 days.

Risk scoring assigns a weighted value to each certificate based on factors that affect its operational and security impact. The components of a risk score include:

Business criticality — what breaks if this certificate fails? Customer-facing services, payment processing, authentication systems, and API gateways carrying revenue-impacting traffic score highest.

Exposure window — time to expiry relative to renewal automation confidence. A certificate 7 days from expiry with working ACME renewal is lower risk than one 30 days from expiry with no automation.

Lifecycle health — has this certificate renewed successfully in the past? How many renewal failures has it experienced? Certificates with a history of renewal problems are higher risk.

Operational complexity — how many systems consume this certificate? Certificates deployed across multiple load balancers, CDN edges, and application servers are harder to rotate and more impactful when they fail.

CA risk — is the issuing CA stable? Has it faced compliance actions? Is it on a distrust trajectory? Post-Entrust, this factor deserves explicit weight.

This scoring model enables prioritised attention. Your operations team focuses on high-risk certificates proactively rather than treating every certificate equally. Dashboards sorted by risk score show you where to look first, every morning.

Dashboards and Alerting Architecture

Certificate observability data serves two audiences, and mixing them degrades both.

Security operations needs CT monitoring alerts, mis-issuance detection, revocation status, and certificates from unauthorised CAs. This feeds into the SOC alongside other security telemetry. The CT monitoring strategy defines the detection layer; observability provides the operational context.

Platform and infrastructure teams need expiry forecasts, renewal pipeline health, CA integration status, and configuration drift detection. This lives in the engineering observability stack — Grafana, Datadog, or whatever your teams use for infrastructure monitoring.

The metrics pipeline should be unified (all certificate data in one collection layer) with the dashboards separated by audience. A SOC analyst doesn't need to see renewal pipeline latency. A platform engineer doesn't need to triage CT alerts. Both need access to the same underlying data if they need to investigate.

Alerting tiers should match organisational response capabilities. Critical: certificate expiry within 24 hours with no successful renewal, issuance failure on a business-critical certificate, mis-issuance detected via CT. Warning: certificate expiry within 7 days, policy violation detected, CA response time degradation. Informational: successful renewals, certificate inventory changes, routine CT matches.

For Kubernetes environments, cert-manager exposes Prometheus metrics natively. Aggregate across clusters for a unified view. For non-Kubernetes infrastructure, certificate scanning tools (both commercial CLM platforms and open-source options like Certspotter for CT and custom scripts for internal scanning) feed the same metrics pipeline.

Discovery: You Can't Monitor What You Haven't Found

Observability assumes you know what certificates exist. Discovery is the prerequisite, and it's harder than most organisations expect.

Certificate discovery has four surfaces. Network scanning finds certificates on listening ports — TLS services, HTTPS endpoints, SMTP servers with STARTTLS. Tools range from commercial CLM platforms to open-source scanners like SSLyze. Network scanning finds certificates that are actively deployed and serving traffic.

Configuration scanning finds certificates in configuration files, key stores, and secret management systems. A certificate in a Kubernetes Secret that's not currently mounted to a Pod won't appear in a network scan, but it's part of your estate and may be consuming a slot against your CA's rate limits.

CT log scanning finds every publicly trusted certificate issued for your domains, including ones you didn't request. This is your CT monitoring strategy doing double duty as a discovery mechanism.

Cloud provider inventory discovers certificates managed by cloud services — AWS Certificate Manager, Azure Key Vault, GCP Certificate Manager. These certificates may not appear in network scans if they're used by managed services (ALBs, CloudFront distributions) that terminate TLS outside your direct infrastructure.

A complete certificate inventory combines all four surfaces, deduplicates, and reconciles. The output is the asset inventory that your observability stack monitors. Discovery isn't a one-time project — it's a continuous process, because certificates are created, deployed, moved, and decommissioned constantly.

From Observability to Intelligence

The progression from monitoring to observability to intelligence maps to three operational maturity levels.

Monitoring (reactive): you know when certificates expire. You respond to alerts. You fix problems after they're detected. This is necessary but insufficient.

Observability (diagnostic): you understand why certificate operations behave the way they do. When a renewal fails, you can trace it to the root cause — CA timeout, DNS validation failure, misconfigured Issuer, rate limit hit. When a certificate is deployed incorrectly, you can identify the configuration drift and correlate it with a deployment change. Observability answers "why" in addition to "what."

Intelligence (predictive): you can forecast certificate operational issues before they manifest. Trending CA response times predict issuance bottlenecks before they cause renewal failures. Certificate estate growth projections inform CA capacity planning. Risk scoring identifies certificates most likely to cause incidents. Intelligence turns certificate management from a cost centre into an operational advantage — you prevent outages rather than respond to them.

Most organisations today are somewhere between monitoring and early observability. The tooling for intelligence exists in mature CLM platforms and can be built with custom observability stacks. The constraint isn't technology — it's the organisational decision to treat certificate operations as a first-class infrastructure concern worthy of SLOs, dashboards, and dedicated attention.

Sector guide: Manufacturing & OT — observability in segmented plants.

A certificate operations view: inventory, ownership, SLOs, and causality when something breaks before the clock runs out.
A certificate operations view: inventory, ownership, SLOs, and causality when something breaks before the clock runs out.

← Back to Certificate Strategy: The Framework Most Organisations Skip

External References