Use a public certificate authority (CA) for anything that browsers, customers or outside systems must trust without any setup, such as public websites and public APIs. Use a private CA for systems you control, such as employee devices, VPN and Wi-Fi access, internal servers, IoT fleets and service-to-service traffic, where you want your own rules, lifetimes and costs.
What a certificate authority does
A CA checks who is asking for a certificate and then signs it. Anyone who trusts the CA’s root certificate will trust the certificates it signs.
So the whole choice comes down to one question: who already trusts your root?
How a public CA works
A public CA’s root certificates ship inside browsers and operating systems through the root programs run by Mozilla, Microsoft, Apple and Google Chrome. That is why everyone trusts its certificates out of the box.
In return, the CA must follow the CA/Browser Forum TLS Baseline Requirements and pass regular independent audits, such as WebTrust for CAs or ETSI-based audits.
As a customer, you accept some limits:
- Validation for every certificate. The CA must confirm that you control each domain name.
- Shrinking lifetimes. The maximum is 200 days today, 100 days from 15 March 2027 and 47 days from 15 March 2029. Our guide to 47-day TLS certificates explains the schedule.
- No internal names. The Baseline Requirements forbid certificates for internal names and reserved IP addresses, such as private address ranges.
- Public logging. Publicly trusted TLS certificates are recorded in public Certificate Transparency logs, because major browsers require it. Your hostnames become visible to anyone who looks.
How a private CA works
You create your own root. Only devices where you install that root, for example through mobile device management, Group Policy or device firmware, will trust it.
You set the rules: certificate profiles, key types, lifetimes, internal names and extra fields.
You also carry the responsibility: protecting the root key, running revocation through CRLs and OCSP, writing the policy and keeping records.
Side-by-side comparison
| Question | Public CA | Private CA |
|---|---|---|
| Who trusts it? | Browsers and operating systems by default | Only devices where you install your root |
| Who sets the rules? | CA/Browser Forum and browser root programs | You |
| Lifetimes | Capped: 200 days now, 47 days from 2029 | Set by your own policy |
| Internal names | Not allowed | Allowed |
| Visible in public logs? | Yes, through Certificate Transparency | No |
| Validation effort | Domain checks for each certificate, plus organization checks for some types | Your own checks, often tied to your directory or device management |
| Cost model | Depends on the CA: per-certificate fees, subscriptions or free automated certificates | Software, HSMs and the people to run them |
| Audit burden | Carried by the CA; you follow its rules | Carried by you |
| Best for | Public websites and public APIs | Internal systems, devices and service traffic |
Which certificates should you issue yourself?
Good fits for a private CA
- Employee laptops and phones, VPN access and Wi-Fi (802.1X with EAP-TLS).
- Internal web apps, service-to-service mutual TLS (mTLS), Kubernetes and service mesh.
- IoT and device identity, where devices may stay in the field for years and need your own certificate profiles.
Keep these on a public CA
- Public websites and public APIs that unknown clients call.
- Anything customers or partners must trust without installing your root.
Grey areas
Partner integrations. Mutual TLS with a small number of partners can use a private CA if both sides agree to trust it.
Document signing. The deciding question is who must verify the signature. If only your own systems check it, a private CA can work. If outside readers must trust it, you need a CA they already trust.
The risks of running a private CA badly
A private CA gives you control, but it also gives you new ways to fail:
- The root key sits on an ordinary server, with no hardware security module (HSM).
- There is one flat CA with no hierarchy, so a single compromise breaks everything.
- Revocation does not really work, so a bad certificate cannot be stopped.
- Leaf certificates are valid for ten years, and nobody keeps an inventory of what was issued.
The fixes are well known: an offline root, issuing CAs below it, keys in an HSM, and a written certificate policy and practice statement (see our guide to common CP/CPS audit gaps). Add a way to track every certificate you issue with Certinium CLM or a similar tool, so nothing expires unnoticed.
Build, buy or managed?
There are four common options: Microsoft Active Directory Certificate Services (ADCS), open-source CA software, commercial CA software, or a managed PKI service.
Ask these questions before you choose:
- Do we need HSMs, and which ones?
- Will the CA run on-premises, in the cloud or both?
- Who runs it at 2 a.m. when something fails?
- How will we move to post-quantum algorithms later?
If you want help with the design, our PKI consulting and architecture design service covers root and intermediate CA hierarchy design and public vs private PKI strategy.
Where DictaLabs CA fits
DictaLabs CA is our enterprise certificate authority platform. It issues, manages and revokes X.509 certificates for users, servers, devices, applications and documents. Its product page lists:
- Root, intermediate, issuing and subordinate CA hierarchies, with offline root CA support.
- Central revocation, with certificate status published through CRLs and OCSP.
- HSM integration over PKCS#11, naming Thales Luna, Entrust nShield, Utimaco CryptoServer, AWS CloudHSM and Azure Key Vault or Managed HSM.
- Self-managed, on-premises, private cloud, public cloud, hybrid, containerized and air-gapped deployment models.
- Integration with Certinium CLM for automated certificate lifecycle operations.
One point applies to every CA product, ours included: good software alone does not make a CA publicly trusted. That takes inclusion in browser root programs and regular audits. As the DictaLabs CA page puts it, formal compliance or certification wording should reflect the exact approved scope of the selected release and deployment.
Next step
If you are deciding which certificates to bring in-house, or designing a CA hierarchy, talk to a PKI expert. You can also ask whether DictaLabs CA fits your environment.
