Private CA (Internal CA, enterprise CA)

A private CA issues certificates outside the public Web PKI. Its root certificate is not in browser or operating-system trust stores, so the organization distributes it itself, for example through device management, container images or configuration management. Common implementations include Microsoft Active Directory Certificate Services, AWS Private CA, the PKI secrets engine in HashiCorp Vault, smallstep step-ca and plain OpenSSL scripts.

Why it matters

Publicly trusted CAs issue only for publicly resolvable domain names and public IP addresses; they no longer issue for internal names such as db.corp or private addresses such as 10.0.0.5. A private CA fills that gap and is the usual choice for mTLS between microservices, VPN and Wi-Fi client certificates, and device identity. It is also outside CA/Browser Forum rules, so you choose lifetimes, key types and EKUs, which matters now that public TLS certificates are losing the clientAuth EKU. The trade-off is that key protection, revocation and root rotation become your responsibility.

Example

Internal Root CA (offline, distributed to company devices)
 └─ Internal Issuing CA (online, automated via ACME or an API)
     ├─ api.internal.example.com (server certificate)
     └─ payments-service (client certificate for mTLS)

Common misconceptions

• A private CA is the same as a self-signed certificate. A private CA is a hierarchy that can issue and revoke many certificates; trusting its root once covers all of them, unlike trusting individual self-signed certificates.
• Private CAs are insecure. Their security depends on how keys and processes are run; a well-operated private CA is standard enterprise practice.
• A private CA can secure a public website. Visitors' browsers will not trust it unless they install your root.