Two Worlds, One Infrastructure
Ask a security team “how many certificates do you have?” and they’ll usually give you the number of public SSL certificates — the ones on their website and customer-facing services. But that’s only half the story. Often less than half.
Internal certificates — issued by your own Certificate Authority, used for machine authentication, encrypted internal traffic, and service-to-service communication — typically outnumber public certificates by 10:1 or more.
These two types of certificates have fundamentally different management challenges, different risk profiles, and different failure modes. Managing one well doesn’t mean you’re managing the other at all.
The Core Differences
| Attribute | Public Certificates | Internal Certificates |
|---|---|---|
| Issued by | Commercial CAs (DigiCert, Let’s Encrypt, Sectigo) | Your own CA (AD CS, private CA) |
| Trusted by | All browsers, phones, operating systems | Only your domain-joined devices |
| Typical count | 50-200 per enterprise | 500-10,000+ per enterprise |
| Cost per cert | $0-$500/year | Free (infrastructure cost only) |
| Lifetime | 90 days - 1 year | 1-5 years |
| Renewal | Manual or ACME automation | Auto-enrollment or manual |
| Visibility | CT logs make them discoverable | Invisible from outside |
| Key concern | Website downtime, browser errors | Service-to-service auth failures |
| Who manages | Security team or DevOps | IT Ops, or nobody |
| Compliance | PCI DSS, browser requirements | Internal policy, SOX controls |
Public Certificates: What They Protect
Public Certificate Deployment Map:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
www.company.com → Company website
api.company.com → Customer-facing API
portal.company.com → Customer portal
mail.company.com → Email (MX/SMTP)
vpn.company.com → VPN gateway
app.company.com → SaaS application
docs.company.com → Documentation site
status.company.com → Status page
cdn.company.com → Content delivery
Total: ~15-50 certificates (typical mid-size enterprise)
Public Certificate Characteristics
Issuers: DigiCert, Let's Encrypt, Sectigo, GlobalSign
Lifetime: 90 days (LE) to 398 days (commercial)
Validation: DV (domain), OV (organization), EV (extended)
Discovery: Easy (CT logs, external scanning)
Monitoring: Many tools available (Uptime Robot, etc.)
Auto-renewal: ACME protocol, cloud-managed (ACM)
Biggest risk: Customer-facing outage → immediate revenue impact
Internal Certificates: The Hidden Majority
Internal Certificate Deployment Map:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Machine Authentication:
• 2,000 workstations (computer auth certs)
• 500 servers (machine identity)
• 200 mobile devices (MDM-enrolled)
Service Authentication:
• SQL Server TLS (15 instances)
• IIS internal sites (45 bindings)
• Exchange internal (3 servers)
• LDAPS on domain controllers (6 DCs)
• RADIUS/NPS (4 servers)
• SCCM/Intune NDES (2 servers)
User Authentication:
• Smart card logon (200 users)
• VPN client certificates (800 users)
• S/MIME email encryption (150 users)
• Wi-Fi user certificates (1,500 users)
Infrastructure:
• IPSec tunnel certificates (12)
• SCOM monitoring (8)
• ADFS token signing (2)
• Federation certificates (4)
Total: ~5,000+ certificates (same mid-size enterprise)
AWS ACM Coverage vs. Total Certificate Estate
What ACM manages vs. what a typical enterprise actually needs
5%
Covered by ACM
95%
Needs separate management
Internal Certificate Characteristics
Issuers: AD CS (your own CA), HashiCorp Vault, EJBCA
Lifetime: 1-5 years (sometimes longer)
Validation: N/A (you control issuance)
Discovery: Hard (no CT logs, must scan internally)
Monitoring: Often none
Auto-renewal: AD CS auto-enrollment (Windows only)
Biggest risk: Auth failures → internal services break silently
Why Managing One Doesn’t Cover the Other
Scenario: “We use AWS ACM for our certificates”
What ACM manages:
✅ Public website certs on ALB/CloudFront
✅ Auto-renewal of those specific certs
✅ API gateway certificates
What ACM does NOT manage:
❌ Internal AD CS certificates (2,000+ machine certs)
❌ On-premises server certificates
❌ VPN certificates
❌ WiFi/802.1X certificates
❌ Code signing certificates
❌ Certificates on other clouds (Azure, GCP)
❌ Database TLS certificates
❌ Docker/Kubernetes internal certificates
Scenario: “AD CS auto-enrollment handles our renewals”
What auto-enrollment manages:
✅ Domain-joined Windows machine certs
✅ User certificates (if templates configured)
✅ Renewal of existing enrolled certs
What auto-enrollment does NOT manage:
❌ Public website certificates
❌ Linux/Mac devices
❌ Cloud workload certificates
❌ Load balancer certificates
❌ Certificates from external CAs
❌ Non-domain devices (BYOD, contractors)
❌ Kubernetes/container certificates
❌ IoT device certificates
Risk Profiles: Different Failures, Different Impacts
Public Certificate Failure
Failure mode: Certificate expires on customer website
Time to detect: Minutes (customers complain immediately)
Business impact: Immediate — revenue loss, trust damage
Visibility: High — everyone sees it
Recovery: Fast — install new cert, restart service
Frequency: Rare (high awareness drives management)
Internal Certificate Failure
Failure mode: Machine auth cert expires on 200 devices
Time to detect: Hours to days (gradual failure, no public visibility)
Business impact: Operational — WiFi failures, VPN drops, auth errors
Visibility: Low — looks like "weird IT issues"
Recovery: Slow — must fix each device, diagnose root cause
Frequency: Common (low awareness, low monitoring)
The Governance Gap
Public Certificates:
☑ Tracked in vendor dashboard (DigiCert, etc.)
☑ Renewal reminders from CA
☑ Visible in CT logs
☑ Browser warnings create urgency
☑ DevOps team actively manages
☑ Budget allocated annually
Internal Certificates:
☐ Tracked in... a spreadsheet? AD CS database? Nowhere?
☐ Renewal reminder... from auto-enrollment? Maybe?
☐ Visible... only if you scan internally
☐ Failure warnings... in Windows Event Viewer (buried)
☐ Managed by... IT Ops? PKI team? The person who set it up 3 years ago?
☐ Budget... "it's free with Windows Server" (but management isn't free)
Bridging the Gap: Unified Management
Why You Need One View
Without unified management:
Team A (DevOps):
"Our public certs are fully managed via ACME"
Blind spot: All internal certs
Team B (IT Ops):
"Auto-enrollment handles everything"
Blind spot: Public certs, non-Windows, cloud
Team C (Cloud):
"ACM auto-renews our cloud certs"
Blind spot: On-prem, internal, non-AWS
Result: Three teams, each managing a slice,
nobody seeing the whole picture
The Unified Approach
| Capability | Public Certs | Internal Certs | Both |
|---|---|---|---|
| Discovery | CT logs, external scan | Network scan, CA query | CLM platform |
| Inventory | CA vendor dashboard | AD CS + manual | Centralized database |
| Monitoring | Uptime services | Custom scripts | Unified alerting |
| Renewal | ACME / manual | Auto-enrollment | Orchestrated workflows |
| Ownership | Defined (usually) | Often undefined | Required for all |
| Compliance | PCI scope clear | Policy unclear | Unified governance |
Practical Comparison: Same Organization, Two Worlds
Certificate Inventory Side-by-Side
ACME Corp Certificate Landscape:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PUBLIC (67 certificates):
┌────────────────────────┬────────┬──────────┬────────────┐
│ Domain │ CA │ Expiry │ Auto-Renew │
├────────────────────────┼────────┼──────────┼────────────┤
│ www.acme.com │ LE │ 85 days │ ✅ ACME │
│ api.acme.com │ LE │ 85 days │ ✅ ACME │
│ portal.acme.com │ DG │ 204 days │ ❌ Manual │
│ mail.acme.com │ DG │ 156 days │ ❌ Manual │
│ vpn.acme.com │ SC │ 12 days │ ❌ Manual │ ⚠️
│ ... 62 more │ │ │ │
└────────────────────────┴────────┴──────────┴────────────┘
INTERNAL (4,230 certificates):
┌────────────────────────┬────────┬──────────┬────────────┐
│ Purpose │ CA │ Count │ Auto-Renew │
├────────────────────────┼────────┼──────────┼────────────┤
│ Machine authentication │ AD CS │ 2,100 │ ⚠️ Partial │
│ User authentication │ AD CS │ 1,200 │ ⚠️ Partial │
│ Web server (internal) │ AD CS │ 89 │ ❌ Manual │
│ LDAPS / DC identity │ AD CS │ 6 │ ✅ Auto │
│ SQL Server TLS │ AD CS │ 15 │ ❌ Manual │
│ RADIUS/NPS │ AD CS │ 4 │ ❌ Manual │
│ IPSec │ AD CS │ 12 │ ❌ Manual │
│ Code signing │ DG │ 3 │ ❌ Manual │
│ K8s ingress │ LE │ 23 │ ✅ cert-mgr│
│ ... more │ │ 778 │ │
└────────────────────────┴────────┴──────────┴────────────┘
Where Outages Actually Come From
Last 12 months - certificate-related incidents:
From public certificates: 1 incident
→ VPN cert expired (vendor forgot to renew)
→ Impact: 4 hours, 200 users affected
From internal certificates: 5 incidents
→ NPS cert expired (WiFi down for 2,000 users): 6 hours
→ Exchange cert expired (email for 1,500): 4 hours
→ SQL TLS cert expired (app outage): 2 hours
→ Auto-enrollment broke (500 devices): 3 days
→ DC cert expired (LDAPS failures): 8 hours
→ Total impact: Multiple days of cumulative disruption
The pattern is clear: internal certificates cause more outages because they receive less attention.
Action Plan: Getting Both Under Control
Step 1: Acknowledge the Gap
Exercise: Answer these questions honestly
Public certificates:
□ How many do we have? Answer: ___
□ Where are they listed? Answer: ___
□ Who renews them? Answer: ___
□ When do they expire next? Answer: ___
Internal certificates:
□ How many do we have? Answer: ___ (if "don't know" → problem)
□ Where are they listed? Answer: ___ (if "nowhere" → problem)
□ Who renews them? Answer: ___ (if "auto-enrollment" → partially covered)
□ When do they expire next? Answer: ___ (if "not sure" → problem)
Step 2: Unified Discovery
Run discovery across both worlds simultaneously:
# External/Public: CT log + active scan
curl -s "https://crt.sh/?q=%.company.com&output=json" | jq '.[].common_name' | sort -u
# Internal: AD CS export + network scan
certutil -view -restrict "Disposition=20" -out "CommonName,NotAfter,CertificateTemplate"
nmap -sV -p 443,8443,636,3389 10.0.0.0/16
Step 3: Unified Monitoring
Both types need the same monitoring approach — just from different vantage points:
| Monitor Type | Public Certs | Internal Certs |
|---|---|---|
| Expiry alerts | External scan every hour | Internal scan daily |
| Health check | HTTPS probe from outside | TLS probe from inside |
| Ownership | Tag in vendor portal | Tag in inventory system |
| Escalation | 30-day alert → team lead | 30-day alert → team lead |
| Emergency | 7-day → incident response | 7-day → incident response |
About QCecuring
QCecuring bridges the gap between public and internal certificate management. Our platform provides unified visibility across all certificate types — whether issued by DigiCert, Let’s Encrypt, AWS ACM, or your own AD CS infrastructure — in a single dashboard with consistent monitoring and alerting.
Tags: public certificates, internal certificates, AD CS, certificate management, PKI architecture, certificate types, enterprise PKI, certificate comparison, visibility gap, CLM