Certificate management is the operational discipline of ensuring every TLS certificate in your infrastructure is discovered, tracked, renewed before expiry, deployed correctly, and governed by policy. It sounds simple. In practice, it’s the #1 cause of preventable outages in enterprise IT.
The average enterprise has 3-10x more certificates than they think. Certificates are deployed by different teams, from different CAs, with different validity periods, on different infrastructure. Without centralized management, certificates expire without warning, get deployed with incomplete chains, or persist long after the services they protect are decommissioned.
Why Certificate Management Matters
The Outage Problem
Expired certificates cause more TLS outages than any other factor:
- Microsoft Teams (2020) — expired authentication certificate, hours of downtime
- Spotify (2020) — expired TLS certificate, global outage
- Let’s Encrypt root expiry (2021) — millions of devices affected
- Equifax (2017) — expired certificate on a security monitoring tool meant the breach went undetected for 76 days
Each incident: preventable with proper certificate management.
The Scale Problem
A mid-size enterprise (2,000 employees) typically has:
- 3,000-8,000 TLS certificates
- Across: web servers, load balancers, APIs, databases, cloud services, Kubernetes, IoT
- From: 3-5 different CAs (Let’s Encrypt, DigiCert, internal CA, cloud CA)
- With: different validity periods (90 days to 2 years)
- Managed by: 5-10 different teams (nobody has the full picture)
The Compliance Problem
Auditors ask:
- “Show me your certificate inventory” (PCI DSS 4.0 Req 4.2.1)
- “How do you ensure certificates don’t expire?” (SOC 2 CC7.1)
- “What’s your cipher suite inventory?” (PCI DSS 4.0 Req 12.3.3)
Without certificate management, you can’t answer these questions.
The Certificate Management Lifecycle
1. Discovery
Find every certificate across your infrastructure:
- Network scanning — probe all IP ranges on TLS ports (443, 8443, 636, 993)
- Cloud APIs — query AWS ACM, Azure Key Vault, GCP Certificate Manager
- Kubernetes — enumerate all
tlsSecrets across clusters - CT logs — monitor Certificate Transparency for certificates issued for your domains
- Agent-based — lightweight agents on servers report local certificates
2. Inventory
For each certificate, record:
- Subject and SANs (what it identifies)
- Issuer (which CA)
- Expiry date (when it dies)
- Key algorithm and size (security posture)
- Deployment location(s) (where it’s used)
- Owner (who’s responsible)
- Renewal method (automated or manual)
3. Monitoring
Continuously verify:
- Expiry — alert at 60, 30, 14, 7 days before expiry
- Chain completeness — server sends full chain (not just leaf)
- Configuration — correct hostname, strong cipher suites, no weak protocols
- Revocation — certificate hasn’t been revoked
- Drift — certificate on disk matches what’s actually served
4. Renewal
Replace certificates before they expire:
- Automated (preferred) — ACME, cert-manager, CLM platform handles everything
- Semi-automated — system alerts, human triggers renewal
- Manual (avoid) — human remembers, generates CSR, submits to CA, downloads, deploys
5. Deployment
Get the new certificate to the right place:
- Write to file system + reload service (Nginx, Apache)
- Update Kubernetes Secret (cert-manager)
- Push via cloud API (ACM, Key Vault)
- Deploy to load balancer (F5, Citrix, AWS ALB)
6. Verification
Confirm the new certificate is actually serving:
# Connect to endpoint and check what's served
echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null | \
openssl x509 -noout -serial -enddate
# Verify serial matches the newly issued certificateCertificate Management Approaches
Level 1: Spreadsheet (Don’t)
❌ Excel spreadsheet with certificate details
❌ Calendar reminders for renewal
❌ Manual CSR generation and submission
❌ SCP to deploy certificates
❌ Hope that nothing was missedReality: Works for 10-20 certificates. Fails catastrophically at 100+.
Level 2: Monitoring Only
⚠️ Prometheus + blackbox_exporter monitors expiry
⚠️ Alerts fire when certificates approach expiry
⚠️ Human responds to alerts and renews manually
⚠️ Better than nothing, but still reactiveReality: Catches expiring certs but doesn’t prevent the problem. Alert fatigue sets in.
Level 3: Automation (Target)
✅ ACME/cert-manager handles renewal automatically
✅ Certificates renewed 30 days before expiry
✅ Deployment automated (reload hooks, Secret updates)
✅ Verification confirms new cert is serving
✅ Monitoring catches automation failuresReality: Eliminates expiry outages for automated certificates. Manual ones still need tracking.
Level 4: Platform (Enterprise)
✅ CLM platform provides single pane of glass
✅ Discovery finds ALL certificates (not just automated ones)
✅ Policy enforcement (approved CAs, key sizes, validity)
✅ Ownership mapping (every cert has a responsible team)
✅ Multi-CA support (Let's Encrypt + DigiCert + internal)
✅ Multi-target deployment (K8s + LB + cloud + legacy)
✅ Compliance reporting (PCI, SOC 2, ISO 27001)Reality: Required for enterprises with 1,000+ certificates across heterogeneous infrastructure.
Tools for Certificate Management
| Tool | Type | Best For | Cost |
|---|---|---|---|
| cert-manager | K8s-native automation | Kubernetes environments | Free |
| Certbot/acme.sh | ACME client | Traditional servers | Free |
| QCecuring CLM | Enterprise platform | Multi-cloud, multi-CA, compliance | Commercial |
| Venafi | Enterprise platform | Large enterprise, machine identity | Commercial |
| Keyfactor | Enterprise platform | Microsoft-heavy environments | Commercial |
| Prometheus + blackbox | Monitoring only | Expiry alerting | Free |
| AWS ACM | Cloud-managed | AWS-only workloads | Free (for AWS services) |
Getting Started: Practical Steps
Week 1: Run a certificate discovery scan. Find out how many certificates you actually have.
Week 2: Identify certificates expiring in the next 90 days. Assign owners. Renew the urgent ones.
Month 1: Deploy ACME automation for all certificates that can be automated (web servers, Kubernetes, cloud LBs).
Month 2: Set up monitoring (Prometheus + blackbox_exporter) for all endpoints. Alert at 30 and 7 days.
Month 3: Address the remaining manual certificates — legacy systems, appliances, partner integrations. Either automate them (CLM platform with push-based deployment) or create documented manual procedures with calendar reminders.
Ongoing: Quarterly review of certificate inventory. Remove orphaned certificates. Update ownership as teams change.
FAQ
Q: How many certificates does a typical enterprise have? A: 3,000-50,000+ depending on size. Most organizations underestimate by 3-10x because certificates are deployed by many teams without central tracking.
Q: What’s the difference between certificate management and PKI? A: PKI is the infrastructure (CAs, hierarchies, trust models). Certificate management is the operational practice of managing the certificates that PKI issues. You need both.
Q: Can’t I just use Let’s Encrypt for everything? A: Let’s Encrypt handles public-facing DV certificates excellently. But it doesn’t cover: internal certificates (mTLS), certificates for non-web services, OV/EV certificates, or certificates on systems that can’t run ACME clients. Enterprise certificate management covers ALL certificate types.
Q: What’s the ROI of certificate management? A: Calculate: (cost of one certificate outage) × (probability per year). A single outage costs $100K-$500K (revenue loss + emergency response + customer impact). With 67% of organizations experiencing at least one per year, the expected annual cost of NOT managing certificates is $67K-$335K. A CLM platform costs far less.
Q: How does this relate to the 47-day certificate validity change? A: The CA/Browser Forum’s move to 47-day maximum validity (by 2029) makes certificate management mandatory — not optional. At 47-day validity, every certificate needs renewal every 6 weeks. Manual management is impossible at that cadence. Read more about 47-day certificates →