Private SSL Certificates: The Invisible Risk Causing Enterprise Outages

TL;DR: Public SSL monitoring tools can only see what's publicly accessible. But most enterprise certificates live on private endpoints—internal APIs, databases, VPNs, and cloud private links—completely invisible to external scanners. These "shadow certificates" cause outages that are harder to diagnose and often more damaging than public certificate failures.

By the Numbers:

• The average organization manages 81,000+ internal certificates
• 38% still track certificates with spreadsheets or homegrown tools
• Certificate outages take 3 hours to identify and 3 hours to fix, involving ~8 team members
• 48% of organizations report customer confidence is affected by certificate outages

Source: Keyfactor 2024 PKI & Digital Trust Report

The Private Certificate Visibility Problem

When we talk about SSL certificate monitoring, we usually think about public-facing websites. Tools like SSL Labs, online checkers, and CT log monitors work well for these—they can reach your domains from the public internet and validate your certificates.

But here's the problem: most certificates aren't public.

In a typical enterprise environment, certificates secure:

• Internal APIs between microservices
• Database connections (PostgreSQL, MySQL, MongoDB with TLS)
• Cloud private endpoints (Private Link, Private Service Connect)
• VPN gateways and internal network access points
• Message queues and event buses (Kafka, RabbitMQ)
• Service mesh mTLS between pods
• Development and staging environments
• On-premises legacy systems

None of these are visible to public monitoring tools. They exist behind firewalls, in private VPCs, or on internal networks. When these certificates expire, you won't get a warning from your external monitoring—you'll get a 3 AM page when production breaks.

Real-World Outages from Internal Certificates

Certificate outages make headlines when they hit public services, but internal certificate failures can be equally devastating—and often harder to diagnose.

Starlink Global Outage

SpaceX's Starlink experienced a multi-hour global outage caused by an expired "ground station certificate." This internal infrastructure certificate took down connectivity for Starlink users worldwide. Elon Musk called it an "inexcusable" single point of failure.

Source: Red Sift - How Expired Certificates Can Cause Service Downtime

Alaska Airlines Ground Stop

A significant IT outage grounded all Alaska Airlines flights in Seattle for several hours. The airline later confirmed the cause as a "certificate issue" that impacted multiple internal systems—not their public-facing website, but backend infrastructure that operations depended on.

Source: Red Sift - Certificate Outage Analysis

The Pattern

These outages share a common thread: the certificates that failed weren't on public websites. They were internal infrastructure certificates that:

• Weren't visible to external monitoring
• Weren't tracked in a central inventory
• Expired without anyone noticing until systems failed

Where Private Certificates Hide

If you've never done a full certificate inventory, you might be surprised where certificates are lurking in your infrastructure:

Cloud Infrastructure

On-Premises / Hybrid

Development & Staging

The challenge isn't just that these certificates exist—it's that they're often managed by different teams, created at different times, and tracked (if at all) in different systems.

Why Traditional Monitoring Falls Short

Public Scanners Can't Reach Private Endpoints

This is obvious but worth stating: if a certificate is on a private network, public monitoring services can't check it. They can't scan internal-api.corp.local or 10.0.1.50:5432.

Blackbox Exporter Works, But...

If you're running Prometheus, you might use Blackbox Exporter to probe internal endpoints. It works, but comes with overhead:

For teams already deep in the Prometheus ecosystem, Blackbox Exporter is a reasonable choice. For everyone else, it's a lot of infrastructure to maintain just to check certificate expiration.

Spreadsheets Don't Scale

According to Keyfactor's research, 38% of organizations still rely on spreadsheets or homegrown tools to track certificates.

Source: Keyfactor - Key Takeaways from 2024 PKI Report

The problems with manual tracking are well-documented:

• No automated alerts when certificates approach expiration
• Inventory becomes stale as infrastructure changes
• No validation that certificates are actually working
• Ownership becomes unclear over time
• Knowledge leaves when team members leave

When certificate volumes reach thousands (the average enterprise manages 81,000+ internal certificates), manual approaches simply break down.

Shadow Certificates

Perhaps the biggest challenge is certificates you don't even know about. Developers deploy certificates without central visibility—sometimes called "shadow certificates."

These certificates:

• Aren't recorded in official inventories
• Often have weak or non-compliant configurations
• May use deprecated cryptographic algorithms
• Get forgotten over time, creating long-term vulnerabilities

Without centralized oversight, these rogue certificates silently increase your attack surface.

Source: AppViewX - How Certificate Discovery Enhances Visibility

What Private Certificate Monitoring Needs

Effective monitoring for private certificates requires a different approach than public certificate monitoring:

1. Runs Inside Your Infrastructure

The monitoring agent must run inside your network perimeter—on a VM, container, or Kubernetes cluster that can reach your private endpoints.

2. No Inbound Access Required

Your private infrastructure shouldn't need to accept inbound connections from external services. The agent should initiate all connections outbound.

3. Full Certificate Validation

Beyond expiration, you need:

• Chain validation — incomplete chains cause failures even with valid certificates
• Revocation checking — OCSP and CRL status
• Weak cryptography detection — SHA-1, small RSA keys, deprecated TLS versions

4. Multi-Channel Alerts

When a certificate is approaching expiration, you need alerts where your team actually sees them—Slack, PagerDuty, Microsoft Teams, email, or webhooks to your existing systems.

5. Centralized Visibility

All certificates—public and private—should be visible in one place. Teams shouldn't need to check multiple systems to understand certificate health.

6. Team-Based Access

Different teams own different certificates. Your monitoring should support organizations, roles, and appropriate access controls.

How CertWatch Agent Solves This

CertWatch Agent is a lightweight, open-source agent that runs inside your infrastructure. It scans certificates on private endpoints and syncs data securely to the CertWatch cloud dashboard.

How It Works

                        ┌──────────────────────────────────────────────────────────┐
                        │                  Your Infrastructure                     │
                        │                                                          │
                        │  ┌──────────────┐    ┌──────────────┐    ┌────────────┐  │
                        │  │ Internal API │    │   Database   │    │    VPN     │  │
                        │  │   :443       │    │    :5432     │    │   :8443    │  │
                        │  └──────┬───────┘    └──────┬───────┘    └─────┬──────┘  │
                        │         │                   │                  │         │
                        │         └───────────────────┼──────────────────┘         │
                        │                             │                            │
                        │                    ┌────────▼─────────┐                  │
                        │                    │  CertWatch Agent │                  │
                        │                    │  (scans certs)   │                  │
                        │                    └────────┬─────────┘                  │
                        │                             │                            │
                        └─────────────────────────────┼────────────────────────────┘
                                                      │ Outbound HTTPS
                                                      ▼
                                            ┌───────────────────┐
                                            │  CertWatch Cloud  │
                                            │  (dashboard +     │
                                            │   alerts)         │
                                            └───────────────────┘

The agent:

• Scans certificates at configurable intervals
• Validates expiration, chain completeness, revocation status, and cryptography strength
• Syncs results to the cloud dashboard
• Sends heartbeats so you're alerted if the agent itself goes offline

What You Get

• Unified dashboard for all certificates (public + private)
• Proactive alerts at customizable thresholds (30/14/7/1 days)
• Multi-channel notifications — Slack, PagerDuty, Microsoft Teams, Email, Webhooks
• Team features — Organizations, roles, invites
• Agent health monitoring — Know if your agent stops reporting

Deploy in Minutes

The agent supports multiple deployment options depending on your infrastructure:

Option 1: Quick Install Script (Linux/macOS)

The fastest way to get started:

curl -sSL https://certwatch.app/install.sh | bash

Then run the interactive setup wizard:

cw-agent init

The wizard guides you through:

• Setting the config file path
• Entering your CertWatch API key
• Configuring agent name and intervals
• Adding certificates to monitor

Option 2: Docker

For containerized environments:

docker run -v $(pwd)/certwatch.yaml:/etc/certwatch/certwatch.yaml \
  ghcr.io/certwatch-app/cw-agent:latest

Or with Docker Compose:

version: '3.8'
services:
  cw-agent:
    image: ghcr.io/certwatch-app/cw-agent:latest
    restart: unless-stopped
    volumes:
      - ./certwatch.yaml:/etc/certwatch/certwatch.yaml:ro

Option 3: systemd Service (Linux VMs)

For traditional Linux servers, create a systemd unit:

# /etc/systemd/system/cw-agent.service
[Unit]
Description=CertWatch Agent
After=network.target

[Service]
Type=simple
User=certwatch
ExecStart=/usr/local/bin/cw-agent start -c /etc/certwatch/certwatch.yaml
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

sudo systemctl enable cw-agent
sudo systemctl start cw-agent

Option 4: Kubernetes (Helm)

For Kubernetes deployments, use our official Helm chart available on ArtifactHub:

helm install cw-agent oci://ghcr.io/certwatch-app/helm-charts/cw-agent \
  --set agent.name=my-cluster \
  --set apiKey.value=YOUR_API_KEY \
  --set "certificates[0].hostname=internal-api.default.svc"

The chart includes secure defaults (non-root, read-only filesystem), Prometheus metrics, and health probes. See the Helm chart documentation for production configuration with secrets.

Example Configuration

Here's a typical configuration for monitoring internal certificates:

api:
  endpoint: "https://api.certwatch.app"
  key: "cw_xxxxxxxx_xxxx..."  # Get from CertWatch dashboard

agent:
  name: "production-internal"
  sync_interval: 5m
  scan_interval: 1m
  metrics_port: 8080      # Prometheus metrics (0 to disable)
  heartbeat_interval: 30s # Agent offline alerts (0 to disable)

certificates:
  # Internal API
  - hostname: "api.internal.corp"
    port: 443
    tags: ["production", "api"]
    notes: "Main internal API gateway"

  # Database with TLS
  - hostname: "postgres.internal.corp"
    port: 5432
    tags: ["production", "database"]

  # VPN endpoint
  - hostname: "vpn.corp.example.com"
    port: 8443
    tags: ["infrastructure", "vpn"]

  # Staging environment
  - hostname: "api.staging.corp"
    port: 443
    tags: ["staging", "api"]

The agent will scan these endpoints, validate certificates, and sync results to your dashboard. You'll get alerts when any certificate approaches expiration—before it causes an outage.

Key Takeaways

1. Most certificates are private — internal APIs, databases, VPNs, and cloud private endpoints outnumber public certificates in most organizations

2. Public monitoring can't see them — external scanners only work for publicly accessible endpoints

3. Internal outages are costly — Starlink, Alaska Airlines, and countless other incidents show that internal certificate failures cause real damage

4. Spreadsheets don't scale — with 81,000+ certificates on average, manual tracking breaks down

5. You need an agent inside your infrastructure — something that can reach private endpoints and report back to a central dashboard

Currently in Beta — Free for Early Adopters

CertWatch is currently in beta, and we're offering early adopters:

• 100 certificates per organization — free during beta
• Unlimited organizations and teams
• All alert channels included — Slack, PagerDuty, Teams, Email, Webhooks
• Help shape the product — your feedback directly influences our roadmap

Stop waiting for the next internal certificate outage. Start monitoring your private certificates today.

Get Started Free →

What's Your Experience?

We built CertWatch because we've experienced the pain of certificate outages ourselves—both public and private. If you have war stories about internal certificates causing problems, or features you wish existed, we'd love to hear from you.

Join our Discord or reach out on Twitter/X.

Sources

1. Keyfactor - 2024 PKI & Digital Trust Report
2. Keyfactor - Key Takeaways from 2024 Report
3. Keyfactor - Certificate Outages a Weekly Reality
4. Red Sift - How Expired Certificates Cause Downtime
5. AppViewX - Certificate Discovery and Visibility
6. Sectigo - What is Certificate Discovery
7. CertWatch Agent Documentation