Key takeaways
- Monitor every certificate you operate, including internal mTLS, private-CA-issued, and cloud-managed certs, not just public websites.
- Fire certificate alerts at 50% of lifetime, then at 30, 14, 7, 3, and 1 days, routed to a named owner with a renewal runbook.
- Query the issuing infrastructure directly, such as AWS Private CA or Vault PKI, to catch client certs that never appear on a listening port.
- ACM auto-renewal can fail silently when DNS validation records are deleted, so monitor renewal eligibility, not just expiry dates.
- Prefer metadata-only monitoring tools that read expiry and ownership records without ever holding secret values.
Certificate expiration monitoring means tracking every certificate you run, not just public websites: internal mTLS services, private-CA-issued certs, ALB and ACM endpoints, and tying each one to a named owner and renewal deadline. Public SSL checkers miss most of that. This guide shows how to build the missing layer with concrete alert thresholds and an ownership model.
What is certificate expiration monitoring and why does it matter?
Certificate expiration monitoring is the practice of tracking the validity windows of every TLS certificate you operate, then firing alerts tied to named owners and renewal deadlines. It goes beyond uptime checks on your public domain: it covers internal services, mTLS pairs, private CA issuers, and cloud-managed endpoints like ACM certificates on load balancers.
What actually breaks when a certificate expires
An expired certificate fails closed. Browsers block your site, API clients reject handshakes, service-to-service mTLS calls drop, and CI jobs that clone over HTTPS stop mid-pipeline. The blast radius is usually wider than the endpoint itself, because expiries cluster: certificates issued on the same day tend to expire on the same day.
The margin you have to work with is shrinking. The CA/Browser Forum approved a schedule that reduces certificate lifetimes to 47 days by 2029, which means renewal windows tighten for every certificate you own (CA/Browser Forum ballot SC-081). We track the lifetime schedule and what it means for rotation planning in our TLS certificate lifetimes brief.
Which certificates should you monitor beyond your public website?
Public endpoints
Start with anything a browser or partner hits: your marketing site, app domains, API gateways, and mail servers. These are the certs an outage gets noticed on fastest, so they usually already have some coverage from uptime checks.
Internal services and mTLS
Internal services are where expiring certificates cause silent failures. Service-to-service mTLS, database client certs, and VPN or bastion certs fail without a browser error to tip anyone off. If a private CA signs them, standard SSL uptime checks never see them at all. Inventory every service that presents or validates a client cert, and treat each as its own monitored asset.
Cloud-managed endpoints (ALB, ACM, API gateways)
Certificates on load balancers, ACM-issued certs, and API gateway custom domains sit behind provider APIs, not your servers. They can still expire or fail renewal, and ACM auto-renewal depends on validation records staying in place. Pull expiry dates from the provider API and monitor them like any other cert.
Client and workload certificates
CI/CD runners, kubectl client certs, and service identities often carry 30/60/90 day rotation policies. Track owner, expiry, and rotation deadline for each:
| Certificate type | Typical owner | Failure mode |
|---|---|---|
| Public TLS | Platform engineering | Browser errors, partner breakage |
| Internal mTLS | Service team | Silent service-to-service failures |
| ACM / ALB certs | Infrastructure | LB serves expired cert |
| Client / workload certs | Individual teams | CI, kubectl, workload auth fails |
KeyGuardRail tracks this metadata, including owner and rotation deadline, without holding the secret value itself; see https://keyguardrail.com/security.
How far before expiry should certificate alerts fire?
A 90-day certificate and a 13-month certificate need different schedules. A practical rule: fire at 50% of lifetime, then at 30, 14, 7, 3, and 1 days. For a 90-day cert, that means your first alert lands around day 45, leaving weeks of runway; for a 397-day cert, you get a two-month heads-up. Anything tighter and a single on-call engineer on PTO can burn your buffer.
Thresholds only work if the alert routes to a named owner with a renewal runbook, not a shared channel. We apply the same expiry-plus-owner model to API keys and tokens, not just TLS; the thresholds differ but the accountability structure is identical.
One caveat: cloud-managed certs may not need alerts at all. ACM renews automatically for eligible resources, but eligibility depends on how the certificate is attached, per AWS documentation on ACM automatic renewal. Monitor the eligibility conditions, not just the expiry date.
How do you monitor certificates issued by private CAs or cloud providers?
Private CA internals: pulling expiry from the issuing infrastructure
If you run AWS Private CA, HashiCorp Vault PKI, or a Microsoft CA, query the issuer directly instead of probing endpoints. Vault exposes issued-cert metadata via its API, and AWS Private CA lists certificates with their NotAfter dates. This catches certs that never appear on a listening port, like client certs used for mTLS or code-signing identities. Inventory the issuer, and expiry monitoring becomes a scheduled API call rather than a network scan.
Cloud-managed certs: ACM, load balancers, and managed endpoints
ACM certificates on an ALB or CloudFront are easy to miss because AWS handles renewal for DNS-validated certs, but renewal fails silently if a CNAME record gets deleted or the domain moves. List every ACM cert in each region, record NotBefore/NotAfter, and check the renewal eligibility status. The same applies to managed endpoints on other providers: treat them as inventory entries with an owner and a renewal runbook, not as things AWS "just handles." The same metadata-only model applies to API keys and secrets, which we cover in our credential expiration reminder guide for IT teams (https://keyguardrail.com/blog/credential-expiration-reminder-tools-for-it-teams).
Network-based probing for internal mTLS
For internal services you cannot inventory at the issuer, probe the endpoint itself with a TLS handshake and read the presented chain. Run the probe from inside the VPC, since private certs will not resolve or verify from a public checker. Store the expiry, SANs, and issuer per endpoint, then apply the same alert thresholds you use for public certs.
Who should own certificate renewal when an alert fires?
Assigning an owner per certificate, not per team
Team-level ownership means nobody is on the hook. Give every certificate a named owner and a backup, recorded alongside its metadata: domain, issuer, NotAfter date (you can pull this from ACM with describe-certificate), and the vault path if a related key lives in AWS Secrets Manager or Infisical. Owners should map to real responsibilities: "Payments platform" owns the Stripe-facing cert, "Platform engineering" owns the internal mTLS chain.
The renewal runbook: what the owner does at each threshold
The runbook is a short checklist the owner executes at 30, 14, and 3 days: confirm the renewal method (ACM auto-renewal, cert-manager, manual CA request), verify deployment targets, and note who approves the change. Write it once per certificate type, not per certificate. A tool like KeyGuardRail (https://keyguardrail.com/) tracks whether each runbook exists and who is assigned, without holding the secret value itself.
Escalation when the owner does not act
If no runbook step is marked done by the 14-day threshold, escalate to the owner's manager automatically; at 3 days, page the on-call rotation. Silent escalation paths are how a named owner still ends up meaning no owner.
How do you choose a certificate expiration monitoring tool?
Criteria: coverage, metadata-only custody, ownership, audit trail
Judge any tool on four things. Coverage: does it reach internal services, mTLS endpoints, private CAs, and cloud-managed endpoints like ACM and load balancers, or only public SSL? Custody: can it monitor expiry from metadata alone, without ever holding the secret value? Ownership: does every certificate carry a named owner and a renewal runbook? Audit trail: can you show who was alerted, when, and what happened next?
That custody question matters more than it looks. A monitoring tool that asks for your credentials to "help rotate them" has just become another secrets sprawl problem. Metadata-only checks, where the tool reads expiry dates and ownership records but never secret values, keep the monitor out of your blast radius.
How the main options compare, including where KeyGuardRail falls short
Vault, Infisical, Dopammer, and Akeyless all store and serve secrets well, and some track expiry for the credentials inside their own inventory. Clutch Security focuses on the identity side of credential exposure. None of them are built as a dedicated lifecycle coordination layer that spans AWS Secrets Manager plus Stripe and GitHub API keys with named owners and rotation deadlines attached. KeyGuardRail is built for exactly that gap: metadata-only credential lifecycle monitoring across your vault and SaaS providers, with ownership and expiry in one place. Where it falls short: it does not store or rotate secrets, so you still need your vault, and its coverage is limited to the integrations it ships today. If you want a single tool that both holds secrets and coordinates their lifecycle, you will run two products or accept a thinner fit.
What happens when a certificate expires unexpectedly?
Treat it as an incident, not a chore. The first job is restoring service: replace the expired certificate, deploy it to every endpoint that references it, and verify clients are connecting again before you investigate anything.
Incident steps: replace, audit, find the gap
Once traffic is healthy, audit the blast radius. Check which services used the expired certificate, whether any mTLS peers or pinned clients failed during the outage, and whether the same certificate is deployed elsewhere. Then find the gap: did the certificate exist in your inventory at all, or was it tracked with no owner and no alert threshold? If it was issued through a vault like HashiCorp Vault, confirm its TTL was recorded against the renewal runbook rather than only in the issuance log.
Closing the loop: why the expiry was missed
Write down the failure mode in one sentence: untracked, unowned, or threshold too late. Fix that specific gap, then re-check the rest of your inventory for the same pattern.
Building your first certificate expiration monitoring setup this week
Start with an inventory, not a tool. List every certificate you can find: public domains, internal mTLS certs, ACM-managed endpoints, and the API keys with expiry dates in Stripe and GitHub. Attach a named owner and a renewal runbook to each entry, because an alert with no owner is just noise.
Next, pick thresholds. A workable default is alerts at 30, 14, and 3 days for public certs, and 90 days for internal certs that need coordination across teams. For keys with a 30/60/90 day rotation policy, treat the rotation deadline as the expiry date.
Then instrument. Use blackbox exporters for public endpoints, AWS CloudWatch on ACM and load balancer metrics for cloud-managed ones, and scheduled API checks for SaaS keys. Route every alert into one channel where the owner is paged by name.
That is enough for week one. Once it runs for a cycle, you will see where secrets sprawl lives and which owners never respond, and that tells you what to automate next.
FAQ
Do I still need certificate expiration monitoring if I use AWS Certificate Manager auto-renewal?
Yes, but monitor the eligibility conditions rather than the expiry date. ACM renews automatically only for eligible resources, and renewal fails silently if a DNS validation record gets deleted or the domain moves. List every ACM cert in each region, check renewal eligibility status, and assign an owner so a failed renewal gets caught before the load balancer serves an expired certificate.
Can a certificate expiration monitoring tool see my secret values or private keys?
It should not need to. Expiry dates, SANs, and issuer details are all available from metadata: provider APIs, issuer APIs, or a TLS handshake that reads the presented chain. A tool that asks for your credentials to help rotate them becomes another secrets sprawl problem. Prefer metadata-only custody, where the monitor reads expiry and ownership records but never holds the secret value itself.
How do I monitor certificates for services behind a VPN or without public domains?
Two approaches. First, query the issuing infrastructure directly: AWS Private CA, HashiCorp Vault PKI, or a Microsoft CA all expose issued-cert metadata with NotAfter dates, which catches client certs that never appear on a listening port. Second, run a TLS handshake probe from inside the VPC, since private certs will not resolve or verify from a public checker. Apply the same alert thresholds either way.
What is the difference between certificate expiration monitoring and full certificate management tooling?
Monitoring tracks expiry windows, ownership, and alerts; it deliberately avoids holding or rotating the secrets themselves. Full management platforms store, issue, and rotate certificates, often within a single vault ecosystem. The gap sits between them: coordinating lifecycle across AWS Secrets Manager, SaaS API keys, and private CAs with named owners and renewal deadlines. Many teams run a vault plus a metadata-only monitoring layer.
How often should I scan my infrastructure for certificates I don't know about?
Run a discovery scan at least weekly, and more often after changes that create certificates: new deployments, CI jobs that issue certs, or team members requesting certs from a private CA. Expiries cluster because certs issued on the same day expire on the same day, so an untracked batch can surface as a simultaneous outage. Weekly scans keep the inventory current between automated issuer API pulls.