Pulseguard
Under Attack?SSL Monitoring
Certificates that never surprise you.
An expired certificate is an outage with a date on the calendar, and it is almost always a renewal job that stopped running weeks earlier. Every scan captures the certificate presented on the wire and compares it with the last one, so both the lapse and the automation failure behind it show up in time.
- Certificate captured
- Every scan
- Kept, not overwritten
- History
- Incident before expiry
- Auto
- Tracked separately
- Per host
Every certificate, and how long it has left.
One card per host with the share of its validity already spent, the chain it presented, and the events that changed it.
- LeafCN=api.vantagerail.com
- IntermediateCN=R11, O=Let's Encrypt
- RootCN=ISRG Root X1
The certificate is never the real problem
Nobody forgets to renew a certificate. What actually happens is that a renewal hook broke silently two months ago and nothing was watching.
Warned with time to act
An approaching expiry opens an incident while there's still room to fix the automation, rather than a notification on the morning it stops working.
Renewals are events too
A successful renewal is recorded as its own event. A host that stops producing them is the earliest signal that the automation has quietly died.
Issuer changes are visible
A certificate that suddenly comes from a different issuer is worth knowing about immediately. It's either a migration nobody mentioned or something considerably worse.
Protocol regressions caught
The negotiated protocol version is recorded on every check, so a server that quietly stops offering TLS 1.3 after a config change shows up as a change rather than a mystery.
Every host, not just the apex
Subdomains carry their own certificates and their own renewal jobs. Each is tracked separately, which is where the forgotten ones live.
History you can audit
Certificate records are appended, never overwritten, so what was presented on a given date is answerable months later.
Recorded on every handshake
Certificate capture is independent of the pass/fail TLS finding: the history exists even when nothing is wrong, which is what makes the comparison possible.
Issuer and subject
Who issued the certificate and what it was issued for, so a swap between providers is a visible change rather than an assumption.
Validity window
Both ends of the window, kept per capture, which is what turns 'expires soon' into a countdown against a known issue date.
Negotiated protocol
The TLS version actually agreed with your server on the check, not the versions it claims to support.
Certificate events
Renewal and expiry-approaching events written to the same timeline as findings, DNS changes, and deployments.
From a handshake to an incident
Nothing here is a separate certificate crawler. It's what the connection already told us, kept.
- 1
The certificate is captured on connect
Each scan records issuer, subject, validity window, and protocol from the certificate the host actually presented, stored as its own history row rather than as a field that gets overwritten.
- 2
It's compared with the previous capture
A new validity window means a renewal; an unchanged one moving toward its end means the clock is running. The comparison is what produces an event, not the reading on its own.
- 3
Approaching expiry opens an incident
An expiring certificate becomes an Incident with a status timeline (Open, Investigating, Monitoring, Resolved), so the fix is tracked rather than assumed.
- 4
The event lands on the timeline
Renewals and expiry warnings sit alongside DNS changes, deployments, and findings, so a certificate problem can be read next to whatever else changed that week.
SSL Monitoring, answered.
Far enough to fix the automation rather than just the certificate. An approaching expiry opens an incident well before the date, and because renewals are recorded as events too, a renewal job that has stopped running is visible even earlier.
Never explain an expired certificate again.
Add a domain and its certificate history starts with the first scan.