Nagios SSL certificate expiry checks

Nagios ssl certificate expiry checks keep datacenters honest when plugins probe the cert files or TLS ports operators control—but they stumble when TLS terminates on a CDN, a wildcard default serves the wrong SNI, or marketing domains outlive the Nagios config lifecycle.

Nagios and its forks (Icinga, Naemon) built the certificate nag workflow: check_ssl_cert, custom check_tcp with openssl s_client, or NRPE scripts that parse notAfter and warn at 30 days. That pattern still works on servers you administer.

The buying context shifted. Hybrid cloud pushes termination to managed load balancers and SaaS edges. Each new hostname used to mean a new service definition; now DNS can point around Nagios entirely until a customer emails a screenshot of an expired cert.

This comparison covers what Nagios does well, where dedicated SSL expiry monitoring differs, fair criteria, and how to keep Nagios for host health while external watches cover public presentation.

What Nagios does well

Nagios remains a dependable choice when checks run close to the workload and ownership is centralized.

Mature plugin ecosystem. check_ssl_cert, custom bash, and community nagios exchange scripts give battle-tested WARN/CRIT thresholds tied to paging policies.

Tight coupling with host checks. Certificate state beside disk, memory, and service checks helps SREs see “renewal succeeded but nginx not reloaded” in one incident view.

On-prem control. Regulated environments that cannot ship metadata to third-party SaaS keep probes inside their network.

Predictable nag escalation. Soft states, flap detection, and parent/child host dependencies still model how operators want certificate warnings to escalate.

Scriptable everything. Your team already encodes org knowledge in Nagios object files; expiry checks inherit the same change management.

Nagios excels for machines and listeners you own end-to-end, not for the full graph of customer-visible DNS names scattered across acquisitions and agencies.

Where SSL expiry monitoring differs

Nagios answers “what did our check command see from this network position?” Continuous external monitoring answers “what does a stranger on the internet get when they type this hostname?”

Public path fidelity. Internal checks against a management IP or vault PEM miss CDN-fronted sites and dual-homed API gateways. External monitors use public DNS and SNI like browsers.

Inventory velocity. Every new microsite or client vanity domain in Nagios requires a human editing objects. SaaS monitors favor self-service adds before launch day.

Registrar lifecycle. Classic Nagios plugins do not query RDAP for domain expiration. TLS may look fine while the domain enters redemption. Pairing RDAP lookup thinking with TLS reduces that surprise.

Chain trust semantics. Parsing notAfter is easy; proving the served chain matches production expectations takes deeper openssl work or a product that surfaces trust issues.

Non-Nagios stakeholders. Marketing and compliance owners need email alerts without learning NRPE or VPN access to the monitoring UI.

Keep Nagios for infrastructure you rack and patch. Add external watches when certificate risk is tied to revenue hostnames Nagios never learned about.

Side-by-side criteria

Evaluate nagios ssl certificate expiry against managed monitors with these ten checks.

1. Probe location. Internal-only vs internet-facing handshake from multiple vantage points.
2. SNI correctness. Each public hostname probed by name, not only IP:443 with default cert.
3. Served vs file expiry. Distinguish PEM on disk from certificate presented after LB rules.
4. Domain registration dates. RDAP or honest unknown when registries withhold expiry.
5. Alert cadence. Staged 30/14/7/1-day notifications with once-per-cycle deduplication after renew.
6. Maintenance burden. Engineer hours per month adding hostnames vs self-service UI.
7. Integrations. Slack/Discord webhooks for teams that no longer read Nagios email summaries.
8. Check frequency. Hourly external polls vs daily cron-style nagios intervals on slow networks.
9. Diagnostic depth. Issuer, SAN list, and chain trust in alert payloads—not only days remaining.
10. Blast radius on misconfig. One wrong parent host dependency should not silence certificate checks on revenue paths.

Walk through a typical plugin command you might already run:

/usr/lib/nagios/plugins/check_ssl_cert -H www.example.com -w 30 -c 7

Compare its output to an external live check on the same name after any CDN or WAF change—disagreement is a probe-path bug, not a false alarm.

How ssldays compares

Do not rip out Nagios where it monitors daemons you administer. Layer ssldays on public hostnames that Nagios never modeled or that terminate far from your agents.

ssldays reads live TLS—issuer, SANs, chain trust, expiry—and RDAP domain dates where published. Alerts at 30, 14, 7, and 1 days, once per threshold per renewal cycle. Email everywhere; Slack and Discord webhooks on Starter and Pro. Free: 3 domains, daily; Starter: 25, hourly; Pro: 100, hourly.

Forward ssldays webhook payloads into the same Slack bridge Nagios already uses so on-call sees one channel. Run quarterly audits: Nagios WARN on check_ssl_cert should match ssldays notAfter on the same listener; if not, your Nagios check probably targets the wrong interface or file.

For script-first diagnostics without Nagios, see bash script SSL expiry patterns—and Grafana certificate dashboards when metrics replace email-only nags.

Common mistakes

Checking /etc/letsencrypt/live while HAProxy serves an old bundle. File age does not equal presentation age.

One Nagios host check per IP with multiple tenants. Default certificates hide per-customer expiry until someone visits the right SNI.

30-day WARNING with no CRITICAL runway. Seven-day pages leave no time for CAB approvals on regulated estates.

Silencing cert checks during deploys without unsilencing. Maintenance windows become permanent blind spots.

Forgetting registrar expiry. Plugins celebrate TLS renewals while the domain fails transfer lock requirements.

Next steps

List every hostname in Nagios SSL-related object definitions. Add any public customer URL missing from that list.

Run each through ssldays free check. Import stragglers into scheduled watches with the alert thresholds your runbook already documents.

Keep Nagios plugins on bastions and admin interfaces; use ssldays for external presentation truth. Document disagreements in a runbook entry tied to openssl check certificate expiry validation steps.