In short: The private vs public certificate authority choice comes down to who needs to trust the certificate. Public CAs are for anything the open internet must validate; a private CA is for internal TLS, mTLS, device and code-signing use cases where you control the trust store and want full control over policy.
Sooner or later every security architecture faces the private vs public certificate authority question: should this certificate come from a publicly trusted CA, or from a certificate authority you run yourself? Get it wrong and you either pay for and rate-limit certificates you did not need to make public, or you try to make an internal CA trusted by browsers it will never reach.
The private vs public certificate authority decision is ultimately about trust boundaries. This article breaks down how CA hierarchies work, when a private CA is the right call, and where only a public CA will do.
Root and issuing CA: how the hierarchy works
A certificate authority rarely signs end-entity certificates with its most valuable key. Instead, an offline root CA signs one or more issuing (intermediate) CAs, and those issuing CAs handle day-to-day certificate requests. The root's private key stays offline in an HSM; if an issuing CA is compromised, it can be revoked without rebuilding the entire trust chain.
This root-and-issuing structure applies whether the CA is private or public. The difference is where the root is trusted: a public root ships in operating system and browser trust stores, while a private root is distributed only to the systems you control.
When to run a private certificate authority
A private CA makes sense whenever the relying parties are inside your control. Internal TLS between services, mutual TLS for APIs and microservices, device certificates for IoT fleets, and internal code signing are all natural fits. You set the policy, issue at volume without per-certificate cost, and use short lifetimes and automation freely.
The trade-off is responsibility: you operate the root, protect its keys and distribute trust. Done well — offline root, HSM-backed issuing CAs, automated lifecycle — a private certificate authority gives you control that a public CA cannot.
When only a public certificate authority will do
Public CAs exist because you cannot pre-distribute your root to the whole internet. Any certificate that unknown parties must validate belongs to a public CA:
- Public-facing websites and APIs, where browsers must trust the certificate without configuration.
- Publicly trusted S/MIME certificates for email signing and encryption with external parties.
- Publicly trusted code signing, where operating systems and app stores check the signature.
- Any service where you do not control the client's trust store.
These certificates follow strict, audited industry requirements and shorter maximum lifetimes, so automation of issuance and renewal is essential.
Choosing between private vs public certificate authority: a checklist
Turn the decision into a repeatable rule with this checklist:
- Ask who must trust the certificate — only your systems, or the open internet?
- For internal TLS, mTLS, device and internal code signing, default to a private CA.
- For public websites, external S/MIME and publicly trusted code signing, use a public CA.
- Whichever you choose, keep the root offline and protect issuing-CA keys in a certified HSM.
- Automate issuance and renewal with ACME, EST or SCEP so nothing expires unnoticed.
- Maintain one inventory across both private and public certificates to avoid blind spots.
How CRYPTAS helps
CRYPTAS helps organisations design the right mix — operating hardened private CAs for internal trust while sourcing publicly trusted certificates where the internet requires them. We build the root and issuing hierarchy, protect keys in HSMs and automate the lifecycle, so the private vs public certificate authority decision becomes a clear policy rather than a recurring debate.
Not sure whether your next certificate needs a private or public CA?