Zabbix SSL certificate expiry monitoring

zabbix ssl certificate monitoring usually means custom items—local PEM parsing, openssl s_client scripts, or HTTP agents—while managed SaaS runs scheduled external live TLS with 30/14/7/1-day alerts and RDAP registration watches without maintaining collectors.

Platform teams already run Zabbix for CPU, disk, and service ports. Certificate expiry becomes a weekend project: a UserParameter reading /etc/letsencrypt/live, a cron-fed notAfter, triggers at 28 days, then drift when someone forgets new microservice hostnames.

Zabbix is a strong choice when you want full control, on-prem data residency, and unified alerting with the rest of infrastructure. This comparison helps you decide when DIY Zabbix SSL items suffice and when external expiry SaaS reduces toil.

You will weigh maintenance cost, external presentation truth, and notification ergonomics against ssldays-style managed monitors.

What Zabbix does well

Zabbix centralizes metrics, logs, and triggers with templated deployments at scale. SSL expiry fits naturally as:

• UserParameters or external checks running openssl x509 -in … -noout -enddate on each app server.
• Scripts that openssl s_client to 127.0.0.1 with -servername for local listeners.
• HTTP agent or web scenarios that hit https:// endpoints from the poller network.

You own retention, RBAC, and escalation—valuable in regulated environments that resist third-party SaaS on certificate metadata.

Discovery can loop certificate stores if you invest engineering time. Dashboards beside kernel patches and queue depth keep operations in one UI.

Strength summary: Zabbix excels when skilled staff maintain scripts, agents reach every cert store you care about, and alerts should flow through existing Zabbix→PagerDuty wiring.

Where SSL expiry monitoring differs

File expiry ≠ presentation expiry. Zabbix on disk catches upcoming notAfter locally but can miss CDN edges, load balancers without updated PEMs, or wrong default certs on shared IPs. External strangers need server vs browser path validation.

Script maintenance tax. OpenSSL flags, SNI requirements, IPv6 monitors, and per-team script forks accumulate. Managed services absorb handshake logic and hostname onboarding UI.

Public inventory onboarding. SaaS products add hostnames without deploying agents through firewalls. Zabbix external checks must originate from network zones that see the same DNS customers use.

Registrar expiry. Zabbix has no built-in RDAP domain registration item; you bolt on WHOIS/RDAP scripts or a parallel product.

Alert semantics. Home-grown triggers often fire daily once under threshold unless deduplicated. ssldays fires once per threshold per renewal cycle at 30, 14, 7, and 1 days—tuned for renewal backlog, not flapping script noise.

Coverage of cloud-managed TLS. Certs you never store on VMs (ACM, Cloudflare edge) need remote probes, not file parses—Zabbix can do it with effort; SaaS defaults to it.

Side-by-side criteria

1. Deployment model. Zabbix: agents, scripts, on-prem pollers. ssldays: no inbound agent; external scheduled handshake.
2. What is measured. Zabbix: whatever your script reads (file, loopback, or remote curl). ssldays: live presented cert (issuer, SANs, chain, expiry).
3. Engineering cost. Zabbix: build, test, version, and document scripts per OS. ssldays: add hostname in UI.
4. Check location. Zabbix internal scripts may not see the internet path. ssldays polls from outside like users.
5. Intervals. Zabbix item interval is yours; ssldays daily (free) or hourly (paid).
6. Alerts. Zabbix triggers + media types. ssldays email + Slack/Discord webhooks on paid plans.
7. Registration expiry. ssldays RDAP built-in; Zabbix needs custom items or manual process.
8. Compliance residency. Zabbix keeps data in your DB; ssldays is SaaS—choose per policy.
9. Hybrid pattern. Zabbix for infra metrics; ssldays for public hostname TLS inventory—common in mid-size teams.

How ssldays compares

ssldays complements Zabbix rather than replacing it. Use Zabbix for hosts, queues, and cert files on servers you control; use ssldays when you want external live TLS on a hostname list without maintaining openssl wrappers.

ssldays reads the certificate the internet receives, alerts at 30, 14, 7, and 1 days via email, and adds Slack/Discord webhooks on Starter (25 domains, hourly) and Pro (100, hourly). Free tier: 3 domains, daily checks.

/check offers immediate external validation when Zabbix shows fresh file dates but customers report warnings—compare serials before closing incidents. Script reference: bash ssl expiry check and openssl expiry for items you keep in Zabbix.

Common mistakes

Monitoring PEM on disk only. Renew succeeded; edge still serves old cert—add external probes.

UserParameters without SNI. Shared IP default certs fake success on wrong hostname.

Trigger spam every hour inside 7-day window. Tune once-per-cycle semantics or adopt a SaaS with deduplicated thresholds.

Forgetting cloud-only certs in Zabbix inventory. List ACM, CDN, and PaaS endpoints explicitly.

Retiring scripts without ownership. Document who updates items when OpenSSL output format shifts.

Next steps

Inventory certs Zabbix already tracks vs public DNS. For each customer-facing name, compare Zabbix notAfter with /check serial.

Where external presentation matters or script debt hurts, register ssldays for the public list while Zabbix watches internal file expiry. Route Zabbix infra alerts and ssldays expiry webhooks to different channels.

Harden remaining Zabbix items using openssl s_client show certs patterns for loopback checks.