Private CA vs. public CA: choosing the right trust model

Not every certificate needs public trust, and not every internal service should automatically use a private CA. The correct choice depends primarily on the relying parties: who or what must trust the certificate, whether you control those systems, and what policy or interoperability requirements apply. The network location of the service matters, but it is not the only decision factor.

What are the key differences between public and private CA trust?

Public CA certificates

A publicly trusted certificate chains to a certificate authority accepted by the relevant public trust programs. For supported browsers, operating systems, and other relying software, that trust is available without your organization first distributing its own private CA certificate. Public trust is therefore designed for broad interoperability outside a single organization's administrative control.

Public trust does not mean the service itself must be on the public internet. An internal application can use a publicly trusted certificate if broad client trust is useful or required. Conversely, an internet-reachable service can use private trust when every client is controlled and provisioned to trust the private CA.

Publicly trusted TLS certificates are subject to browser and CA/Browser Forum requirements, including domain validation and maximum validity limits. DigiCert's current public TLS validity schedule should be treated as the authoritative source for current dates.

Public trust is usually the right fit when:

A website, API, portal, or service must be trusted by customers, partners, unmanaged devices, or other clients whose trust stores you cannot configure.
You need standard public-web interoperability without distributing a private root or intermediate CA certificate to every relying party.
The use case requires a publicly trusted TLS certificate and must comply with public-trust validation, issuance, and lifetime requirements.
A third party explicitly requires a certificate chaining to an accepted public CA.

Private CA certificates

A privately trusted certificate chains to a CA that is trusted only by systems you configure to trust it. A private CA can be operated by your organization or provided as a managed/private-PKI service. What makes it "private" is the trust model, not where the CA software is hosted.

Private trust is usually the right fit when:

The relying systems are under your administrative control and you can reliably distribute, update, and remove private trust anchors.
You are securing internal TLS, mutual TLS (mTLS), workload identities, service-to-service communication, users, or managed devices.
You need certificate profiles, naming conventions, validity periods, or identity models that are specific to your internal environment and not appropriate for public trust.
The environment is isolated or highly controlled and is intentionally designed around private trust.

What the move toward shorter public TLS validity actually means

The public TLS ecosystem is moving to progressively shorter certificate lifetimes, but the 47-day maximum is not the current limit. The CA/Browser Forum schedule reduces maximum public TLS certificate validity in stages. Beginning March 15, 2026, the forum maximum is 200 days. DigiCert uses a 199-day maximum. The schedule moves to 100 days in 2027 and 47 days in 2029, with DigiCert generally using one day less than the forum maximum to avoid exceeding it.

Mar. 15, 2026 to Mar. 15, 2027 — CA/Browser Forum maximum 200 days; DigiCert maximum 199 days.
Mar. 15, 2027 to Mar. 15, 2029 — CA/Browser Forum maximum 100 days; DigiCert maximum 99 days.
After Mar. 15, 2029 — CA/Browser Forum maximum 47 days; DigiCert maximum 46 days.

These limits apply to publicly trusted TLS server certificates, not to every public-key certificate and not automatically to privately trusted certificates. A private CA therefore gives an organization control over its internal certificate lifetimes, but avoiding public-TLS lifetime rules should not be the sole reason to redesign a trust architecture. Shorter lifetimes can also be a security objective for private PKI, especially for workload identities and mTLS.

Private PKI is not a zero-operational-cost alternative

Moving an internal use case to private trust changes the operating responsibilities rather than eliminating them. Depending on the deployment model, those responsibilities can include:

Designing the CA hierarchy and protecting root and issuing CA keys.
Distributing and maintaining trusted CA certificates on every relying system.
Defining certificate profiles, naming rules, authorization, and issuance policy.
Operating or consuming certificate status services such as CRLs and OCSP where required by the design.
Planning CA certificate renewal, rollover, compromise response, backup, and disaster recovery.
Automating enrollment, deployment, renewal, and post-deployment validation so shorter internal lifetimes remain operationally safe.

Most enterprises need a hybrid trust architecture

For many organizations, the correct architecture is not "public or private." It is a governed combination of both. Public trust covers services that need broad recognition. Private trust covers identities and services where the organization controls the relying systems. The two populations can have different policies, certificate lifetimes, validation requirements, and automation patterns while still being governed through a common lifecycle-management model.

Where DigiCert fits

DigiCert Trust Lifecycle Manager (TLM) provides centralized certificate lifecycle management across public and private trust sources. TLM natively supports private certificate issuance from DigiCert Private CA. For other supported public or private issuing CAs, TLM uses CA connectors for issuance and management. Its current connector catalog includes DigiCert CertCentral, AWS Private CA, Microsoft CA, EJBCA, Entrust, GlobalSign, Let's Encrypt, Sectigo, Step CA, and others.

What centralized management can provide, when the relevant CA and deployment integrations are configured:

Consolidated certificate inventory built from issuing-CA integrations, connectors, discovery, and other supported data sources.
Certificate profiles and policy controls for issuance that are performed through TLM-supported workflows.
Managed automation or ACME/API-based automation for supported deployment targets and use cases.
Lifecycle actions such as renewal or revocation where TLM has the required access to the issuing CA.
Consistent ownership, tagging, reporting, and operational visibility across certificate populations.

DigiCert Private CA is DigiCert's private PKI offering for issuing privately trusted certificates to users, devices, applications, and other digital assets. It supports both DigiCert-hosted and customer-hosted deployment models.

Frequently asked questions

Will browsers trust a private CA automatically?

No, a private CA is not part of the public browser/operating-system trust ecosystem. A browser or other relying client will trust a privately issued certificate only when the appropriate private CA trust anchor has been installed or otherwise configured as trusted. How that trust is distributed depends on the device, operating system, application, and management model.

Does every public-facing service require a publicly trusted certificate?

Not necessarily. Internet reachability and trust are separate questions. If every client is controlled by your organization and is configured to trust your private CA, an internet-reachable service can technically use private trust. Public trust is required when the service must be trusted by relying parties whose trust stores you do not control or when a use case or third party specifically requires public trust.

Do the public TLS validity reductions apply to private certificates?

No, the CA/Browser Forum TLS certificate validity schedule applies to publicly trusted TLS server certificates governed by those requirements. Private PKI certificate lifetimes are set by the organization and its CA policies, subject to product and cryptographic constraints. Many organizations still choose short-lived private certificates for security and automation reasons.

Can DigiCert help us operate private PKI?

Yes, DigiCert Private CA provides private-trust PKI capabilities, and Trust Lifecycle Manager can issue and manage certificates from DigiCert Private CA. We also support customer-hosted and DigiCert-hosted Private CA deployment models. For supported external private CAs, TLM can use CA connectors to bring issuance and management into the lifecycle platform.

Can Trust Lifecycle Manager manage certificates from non-DigiCert CAs?

Yes, for supported issuing CAs and use cases. TLM is CA-agnostic and provides CA connectors for a range of public and private CAs. The exact actions available depend on the CA connector, certificate type, licensing, and whether TLM has the required access to the issuing CA.

Who is responsible for CRL and OCSP infrastructure with a private CA?

It depends on the private-CA deployment model. In a customer-hosted PKI, your organization typically designs and operates the required revocation publication and responder infrastructure. In a managed or DigiCert-hosted model, the service provides some infrastructure responsibilities. The relying applications still determine whether and how revocation information is checked.