Or just use traefik or caddy or certbot.
Oncidentally, I wonder how the SSL companies still run when we have the wonderful LE or ZeroSSL. A cert is a free utility today and not worth overthinking.
Oncidentally, I wonder how the SSL companies still run when we have the wonderful LE or ZeroSSL. A cert is a free utility today and not worth overthinking.
That said, a lot of enterprise environments still deal with: - Air-gapped networks (no LE/ZeroSSL reachability) - Mutual TLS between services, where certs aren’t tied to domains - Manually issued certs from internal or private CAs (often via ticketing systems) - Non-HTTP workloads that don’t play well with ACME automation
In those cases, certs are still a bit of a pain, especially when ownership is unclear or spread across teams. SSL Guardian aims to help in those more chaotic setups, not just the clean webserver use cases.
We already have an api endpoint in place, so you can push data using Python, Bash, curl, or anything else that fits your workflow. No agent required, just a simple POST.
Just issue them locally (within the airgapped network) and keep track of them based on issue date.
But in practice, large or long-running environments rarely have clean cert inventories. You get:
- Internal CA sprawl (and no single source of truth)
Certs embedded in keystores, containers, or staging systems that nobody owns anymore
- “Temporary” certs that live on for years - People leaving without handing off cert responsibilities
We’re not automating monitoring because it’s hard, we’re doing it because teams forget.
And forgetting is what causes outages, broken mTLS, and failed compliance audits, even in air-gapped setups. I have a few horror story on PCI environments.
Automation helps catch the edge cases before they become fire drills.