# Public Trust and Private Trust

Digital certificates don't operate in a vacuum - they operate within defined trust models that determine where and how a certificate is actually trusted. The two primary trust models you'll encounter in enterprise environments are public trust and private trust. Getting this distinction right is foundational to designing a certificate strategy that's both secure and scalable.

#### Public Trust

Public trust covers certificates issued by Certificate Authorities whose root certificates are embedded in major browsers, operating systems, and devices. Because of that pre-distribution, certificates issued under public trust are automatically recognized by external users and systems - no additional configuration required on the relying party's side.

Publicly trusted certificates are typically used for internet-facing websites and applications (HTTPS/TLS), public APIs and services, and external customer- or partner-facing platforms.

CERTInext supports public trust certificates through integrations with public CAs and through its own public trust infrastructure. Specifically, CERTInext uses the emSign public trust anchor, which is owned and operated by CERTInext's group entities and is trusted across major global browsers and operating systems. This means you can issue and manage publicly trusted certificates within CERTInext while maintaining consistent lifecycle governance and automation - rather than treating public certificates as a separate, disconnected concern.

#### Private Trust

Private trust refers to certificates issued by internal or enterprise-controlled Certificate Authorities. These certificates are trusted only within environments where the corresponding root or intermediate certificates have been explicitly installed. They're not visible or trusted by the public internet.

Private trust certificates are commonly used for internal applications and services, machine-to-machine and service-to-service communication, device and workload authentication, and IoT or industrial closed-network environments.

The tricky part here is distribution. Private trust gives you greater control over certificate policies, lifecycles, and trust boundaries - but it requires careful management to ensure trust anchors are properly deployed and maintained. A private CA root that isn't distributed to all the right endpoints creates trust failures that can be surprisingly hard to diagnose.

#### Managing Public and Private Trust in CERTInext

CERTInext manages both public and private trust models from a single platform. It provides centralized visibility into certificates issued under different trust anchors, applies consistent policies across trust domains, and automates lifecycle operations regardless of where certificates were issued or deployed.

By supporting public trust (including the emSign trust anchor) alongside private trust, you can align certificate usage with security and exposure requirements, reduce operational complexity across mixed trust environments, and enforce consistent governance and auditability - without having to run separate tooling for each trust model.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.certinext.io/documentation/getting-started/key-concepts-and-terminology/public-trust-and-private-trust.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
