Internal CA vs. Public CA: What Each Handles (And What Falls Through)
The Problem
“We use DigiCert for our certificates.” “We have Let’s Encrypt set up.” “AWS ACM handles our certificate management.”
These statements are true — for external websites. They cover exactly zero percent of your internal certificate landscape.
The gap between public CA management and internal CA management is where outages live. This post maps out what each world handles and what falls through the crack between them.
Two Completely Different Worlds
| Dimension | Public CA | Internal CA (AD CS) |
|---|---|---|
| Purpose | External websites, public-facing services | VPN, WiFi, device auth, internal apps, code signing |
| Examples | DigiCert, Let’s Encrypt, Sectigo, AWS ACM | Microsoft AD CS, EJBCA, Vault PKI |
| Trust model | Browser/OS trust store | Enterprise GPO-distributed trust |
| Validation | Domain/Organization/Extended | Machine identity, user identity |
| Lifecycle | 90 days (LE) to 1 year | 1-5 years (certs), 5-20 years (CA certs) |
| Renewal | ACME automated | Auto-enrollment (GPO-dependent) |
| Volume | Dozens to hundreds | Hundreds to thousands |
| Visibility | CT logs, vendor dashboards | Often: nothing |
| Failure impact | Website shows warning | VPN/WiFi/auth stops working |
What Public CAs Handle
Public CAs issue certificates for things that face the internet:
- Web servers — HTTPS for your external sites
- API endpoints — TLS for public APIs
- Email gateways — TLS for SMTP
- CDN/Load balancers — Edge termination
Public CA Management Is (Mostly) Solved
| Tool | What It Does |
|---|---|
| Let’s Encrypt + ACME | Auto-renews every 90 days. Set and forget. |
| AWS ACM | Managed certificates for AWS-hosted services. Auto-renews. |
| Cloudflare | Handles edge certs entirely. Zero management. |
| DigiCert CertCentral | Dashboard, expiry alerts, team management |
| Venafi / Keyfactor | Enterprise-grade lifecycle management |
For public certificates, the tooling is mature. ACME protocols automate renewal. Certificate Transparency logs provide visibility. Browser warnings surface problems immediately.
The problem is not public certificates.
What Internal CAs Handle
Internal CAs (primarily Microsoft AD CS in enterprise environments) issue certificates for everything else:
- Machine authentication — Device identity for WiFi (802.1X), VPN (IKEv2), and conditional access
- User authentication — Smart card logon, client auth certificates
- Server authentication — Internal web apps, LDAPS, SQL Server encryption
- Code signing — Internal scripts, PowerShell execution policies
- Encryption — EFS, S/MIME email encryption
- Infrastructure — SCCM, SCOM, RDP, network devices
The Scale Difference
A typical enterprise with 5,000 employees might have:
| Category | Public Certs | Internal Certs |
|---|---|---|
| Web servers | 30-80 | 50-200 (internal apps) |
| Machine auth | 0 | 3,000-5,000 |
| User auth | 0 | 1,000-5,000 |
| Code signing | 2-5 | 10-50 |
| Infrastructure | 5-10 | 100-500 |
| Total | ~100 | ~5,000-10,000 |
Internal certificates outnumber public certificates 50:1 to 100:1 in most enterprises.
What Falls Through the Gap
Here’s the problem: organizations solve public certificate management and assume they’ve solved “certificate management.” They haven’t.
Gap 1: No Visibility
Public certificates have Certificate Transparency logs. Anyone can see them. Internal certificates have… nothing. No CT logs. No central dashboard unless you build one.
Question: How many internal certificates does your AD CS have issued right now? If you can’t answer that in 30 seconds, you have a visibility gap.
Gap 2: Different Renewal Mechanisms
Public certificates use ACME — a protocol specifically designed for automated renewal. It works reliably because:
- The renewal system has internet access (by definition)
- Validation is domain-based (DNS or HTTP challenge)
- No dependency on device state or user login
Internal certificates use auto-enrollment, which requires:
- Device on the corporate network (or VPN)
- Device powered on during the renewal window
- AD connectivity and Group Policy processing
- Template permissions and enrollment rights intact
- CA server reachable
ACME works because it’s simple. Auto-enrollment fails because it has dependencies.
Gap 3: Different Failure Modes
| When a public cert expires… | When an internal cert expires… |
|---|---|
| Browser shows warning | VPN silently fails |
| Users see padlock = broken | WiFi authentication denied |
| Monitoring tools catch it immediately | Nobody knows until users report |
| Fix: Re-issue via dashboard | Fix: Re-enroll device (needs network access) |
| Impact: One website | Impact: Potentially thousands of devices |
Gap 4: AWS ACM Doesn’t Cover Internal PKI
A common assumption: “We use AWS ACM, so our certificates are managed.”
AWS ACM handles:
- ✅ Certificates for ALBs, CloudFront, API Gateway
- ✅ Auto-renewal for AWS-integrated services
- ❌ Machine certificates on domain-joined devices
- ❌ VPN client certificates
- ❌ WiFi authentication certificates
- ❌ Internal server certificates (LDAPS, SQL, RDP)
- ❌ AD CS-issued certificates of any kind
ACM and AD CS serve completely different purposes. Using ACM doesn’t reduce your internal PKI management burden by a single certificate.
Gap 5: Different Lifecycles
| Certificate Type | Typical Lifetime | Renewal Strategy |
|---|---|---|
| Let’s Encrypt | 90 days | ACME (fully automated) |
| Public DV/OV | 1 year | Dashboard + alerts |
| Machine cert (AD CS) | 1-2 years | Auto-enrollment (fragile) |
| User cert (AD CS) | 1-2 years | Auto-enrollment (fragile) |
| Issuing CA (AD CS) | 5-10 years | Manual (forgotten) |
| Root CA (AD CS) | 10-20 years | Manual (definitely forgotten) |
The longer the lifetime, the more likely it’s forgotten. CA certificates with 10-20 year lifetimes are the most dangerous because nobody who configured them will still be on the team when they expire.
The Real-World Scenario
Organization has “certificate management handled”:
- ✅ Let’s Encrypt with auto-renewal for external sites
- ✅ AWS ACM for cloud infrastructure
- ✅ DigiCert for high-assurance public certs
- ❌ 4,000 machine certificates issued by AD CS with no tracking
- ❌ 200 internal server certificates manually installed
- ❌ 2 intermediate CA certificates expiring in 8 months (nobody knows)
The public side is solved. The internal side is a ticking clock.
What Internal Certificate Management Requires
| Requirement | Purpose |
|---|---|
| Complete inventory | Know every cert AD CS has issued — active, expired, revoked |
| Expiry monitoring | Alert before any cert expires — including CA certs |
| Deployment verification | Confirm certs are actually installed on target systems |
| CRL/OCSP health | Monitor revocation infrastructure availability |
| Template auditing | Track who can enroll what, and where |
| Lifecycle reporting | Know what’s expiring this month, next quarter, next year |
The Bottom Line
Public CA management is solved. The tools exist, they work, and they’re mature.
Internal CA management is not solved for most organizations. Different protocols, different failure modes, different scale, different consequences. And the tools that manage public certificates don’t touch internal ones.
If your “certificate management strategy” only covers public certificates, you’re managing 100 certs and ignoring 5,000.
Need visibility into your internal certificate landscape? QCecuring bridges the gap between public CA tools and internal PKI. We monitor AD CS-issued certificates, CRL health, and CA certificate expiry. Let’s talk →