SSL certificate monitoring
Certificates always seem to expire at 2am.
SSL certificate monitoring tracks the state of every certificate you run in real time, and
alerts you before one expires. It is how a missed renewal stops being a 2am outage and
becomes a notice you act on with time to spare.
Start free trial
See how it works
What is SSL certificate monitoring?
SSL certificate monitoring is the practice of continuously checking every SSL (TLS) certificate
your infrastructure depends on, and alerting before it causes an outage.
That means watching expiration dates, verifying that the signing authority is still trusted,
and confirming the certificate on the wire is the one you actually deployed.
What a check actually inspects
your monitor your endpoint
│ │
│──────── TLS handshake ───────►│
│◄───── certificate + chain ──────│
│
├─ notAfter date .......... how long until it expires?
├─ subject / SANs ......... does it cover this hostname?
├─ issuer chain ........... is the intermediate still trusted?
└─ served certificate ..... is this the one you deployed?
A date in a spreadsheet can't answer these questions.
Why this is getting harder, fast
Certificate lifetimes are shrinking. The 200-day maximum is already in effect, and the
industry is on a path to 47-day certificates by 2029. A renewal that used to happen once a
year will need to happen roughly twelve times a year, on every certificate, on every system
that serves it.
That changes what monitoring is for. At one renewal a year, a calendar reminder is a
reasonable monitoring strategy. At eight, the renewals blur together, and the question stops
being "when does this expire" and becomes "did every one of the last forty renewals actually
land." Monitoring shifts from a countdown to a verification loop.
Read about the certificate lifetime mandate
Alerts before an outage, not after
The point of certificate expiration monitoring is lead time. Continuous checks mean you get
a notice well before an expiry, so a renewal is something handled on a normal workday, not a
fire fought after a site is already down.
issued CertKit alerts expiry
●──────────────────────────●──────────────────────────●
▲
before the outage, not after
Continuous checks mean you act on a notice, not on a customer complaint.
CertKit also verifies each renewal after it happens, confirming the new certificate is the
one actually being served.
SSL monitoring vs. uptime monitoring
Most uptime monitoring platforms include an SSL check, and if you already run one, keep it.
But the two answer different questions, and the difference matters when a certificate is the
thing that broke.
Uptime monitoring
Probes a public URL on a schedule and reports whether it responded. The SSL check is a
property of that probe: it sees the certificate on the endpoints you listed, and warns
when one is close to expiring.
That covers your public web endpoints well. It does not see a load balancer's management
interface, a VPN appliance, a mail server, an internal service, or a certificate that
exists but was never added to the list.
Certificate monitoring
Starts from the certificate inventory rather than from a list of URLs. It knows what was
issued, where each one was deployed, whether the last renewal succeeded, and whether the
certificate on the wire matches the one that was supposed to be installed.
It also covers the certificates with no HTTP endpoint to probe, and finds the ones nobody
told it about by reading Certificate Transparency logs.
The practical difference is coverage. Uptime monitoring tells you a page is down. Certificate
monitoring tells you which certificate did it, on which host, and whether anything else is
about to follow.
What to look for in an SSL certificate monitoring tool
Most SSL monitoring tools do expiry monitoring and nothing else: a list of hostnames you
maintain, checked for an expiry date. That is the easy part of the problem. When evaluating
an SSL cert monitoring tool, check that it covers the rest:
- Discovery, not just a list you maintain. If you have to add every hostname by hand, the tool can only monitor the certificates you already remembered. The forgotten ones are the ones that expire.
- Verification of the served certificate, so a renewal that never reached the server is caught, instead of being marked renewed in a dashboard.
- Renewal failure alerts, separate from expiry alerts. A silent automation failure needs to page you weeks before the expiry does.
- Chain and trust store checks, so a revoked or distrusted intermediate registers as a problem while the certificate is still technically valid.
- Coverage beyond public web endpoints: appliances, mail servers, internal hostnames, and client certificates.
- Alerting that reaches the on-call rotation, not just an inbox someone reads on Mondays.
Then ask the question most tools dodge: when it finds an expiring certificate, what happens
next? A monitoring tool hands you a ticket. That's a fair answer, but it is worth knowing
it's the answer before you buy.
Monitoring tells you. Automation fixes it.
An SSL certificate monitoring tool is the right place to start: it stops surprises and costs
you nothing in risk. But a monitoring tool only tells you a certificate is about to expire.
Someone still has to renew and redeploy it. The next step is
automating the renewal, so the fix happens on its own
and monitoring is just there to confirm it worked.
Together, discovery, automation, and monitoring are
certificate lifecycle management. CertKit
finds every certificate you have, renews and deploys
it automatically, and monitors every one so nothing slips through.
Start free trial
See how it works
Frequently asked questions
What does CertKit monitor?
Expiration dates on every certificate across your domains, whether each renewal
succeeds, whether the right certificate is actually being served on the live endpoint,
and whether its chain of trust is still valid. If any of those is off, you get an alert.
How will I be alerted before a certificate expires?
CertKit checks your certificates continuously and alerts you ahead of each expiry, and
again if an automated renewal fails. The lead time is the point, so you act before an
outage rather than after one.
Does monitoring confirm the right certificate is being served?
Yes. CertKit checks the live TLS handshake after each renewal and confirms the new
certificate is the one actually in place, not an old or mismatched one left behind by a
half-finished deploy.
How to verify certificate renewal
Can I monitor certificates CertKit didn't issue?
Yes. Monitoring works on any public endpoint, so you can watch certificates you got
elsewhere, not only the ones CertKit manages. It is a good way to get visibility before
you automate anything.
Find every certificate you have
Can I monitor internal and private certificates?
Yes. Certificates CertKit issues are tracked from issuance onward whether they come from a
public CA or your private one, so internal hostnames, IP address certificates, and mTLS
client certificates sit in the same inventory and the same alerts as everything else,
without needing a public endpoint to probe.
About managed PKI
Do I need this if my uptime monitoring already checks SSL?
It depends on what else you run. An uptime monitor covers the public URLs you gave it,
which may be all the certificates you have. If you also run appliances, mail servers,
internal services, or certificates issued by teams outside your list, those are the ones
that expire unnoticed, because nothing is probing them.
How do I get started?
Start a 90-day free trial, no credit card required. Add your domains and CertKit begins
monitoring expiration and renewal status right away. Our engineering team helps you set
up.
See pricing
Stop watching expiry dates by hand
Free 90-day trial. No credit card required.
Direct access to our engineering team to get you set up.
Start free trial
See pricing