7 ms·

Totally fair, for public-facing web servers, Traefik, Caddy, and Let’s Encrypt have made things nearly zero-effort. It’s amazing how far we’ve come. That said,

Totally fair, for public-facing web servers, Traefik, Caddy, and Let’s Encrypt have made things nearly zero-effort. It’s amazing how far we’ve come. 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.

chucksta 1y ago
How does it monitor a cert in an air-gap network?
- ignaciovdk 1y ago
  We're building a lightweight collector (RTCollector) you can run inside the air-gapped environment. It can read from local cert stores (JKS, PKCS#12, PEM, etc.), extract metadata like expiration date and fingerprint (no private keys or cert contents), and send it out securely when outbound connectivity is available. 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.
- M95D 1y ago
  Why would an air-gapped network need public certs? Or how would they update them except manually? Then why would they automate the monitoring? Just issue them locally (within the airgapped network) and keep track of them based on issue date.
  - ignaciovdk 1y ago
    That’s a fair question, and in theory, yes, you could manually track internal certs 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.

chucksta 1y ago

How does it monitor a cert in an air-gap network?

ignaciovdk 1y ago
We're building a lightweight collector (RTCollector) you can run inside the air-gapped environment. It can read from local cert stores (JKS, PKCS#12, PEM, etc.), extract metadata like expiration date and fingerprint (no private keys or cert contents), and send it out securely when outbound connectivity is available. 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.
M95D 1y ago
Why would an air-gapped network need public certs? Or how would they update them except manually? Then why would they automate the monitoring? Just issue them locally (within the airgapped network) and keep track of them based on issue date.
- ignaciovdk 1y ago
  That’s a fair question, and in theory, yes, you could manually track internal certs 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.