What is a private CA? Internal certificate authorities and when to use one

9 min readUpdated Oct 2026

A private CA is a certificate authority whose root certificate you distribute yourself, to the devices and programs you control, instead of having it shipped inside browsers and operating systems. Certificates it issues are accepted only where that root is installed. That is why a private CA fits internal services and fails on the public web. This page covers when to choose one, how trust reaches a device, and what you take on by running it. For what a certificate contains, start with the SSL certificate guide. For the role every CA plays, public or private, see what a certificate authority does.

Public trust: A certificate is publicly trusted when its root is distributed as a trust anchor in widely-available application software; a private CA's root is not ^[1]
Names: A CA that follows the Baseline Requirements may not issue certificates containing internal names or reserved IP addresses ^[1]
Trust: Path validation takes the trust anchor as an input, so the root of a private CA has to be supplied as one ^[2]
Scope: A name constraint, placed in a CA certificate, confines every certificate below it to one name space ^[2]
Tooling: OpenSSL's own manual calls its ca command a sample minimal CA application ^[8]

Public CA or private CA: how to choose

Choose a public CA when visitors you do not control must trust the certificate. Choose a private CA when you control every device that connects and the names are internal. One organisation can run both.

If you need public trust and no private root, the options that cost nothing are covered on the page about free public certificate authorities.

Public CA or private CA: how to choose
Question	Public CA	Private CA
Who must trust the certificate	Any visitor's browser, with nothing installed	Only devices where you installed the root
Names it can cover	Names that resolve in the public DNS; internal names and reserved IP addresses are excluded ^[1]	Any names you choose, internal ones included
Who decides what is trusted	The browser and operating system root programs	You
Who answers for how the CA is run	The CA operator, under root program rules	You

The last row is the cost. The checks that root programs place on public CAs are described on the certificate authority page; none of them comes with a private CA unless you arrange it.

A single self-signed certificate has to be trusted one server at a time. A private CA is trusted once, at the root, and every certificate it issues is accepted from then on. The more internal services you run, the more that difference counts.

How a device comes to trust a private root

A device trusts a private CA only after someone puts the root of that private certificate authority where the device looks for trust anchors. Path validation, as RFC 5280 defines it, takes trust anchor information as an input ^[2]. A chain that leads to a root the device does not hold fails. Each platform has its own step, and the root certificate page describes the stores:

iPhone and iPad. Installing the root profile is not enough. Full trust is switched on separately, under Settings > General > About > Certificate Trust Settings ^[3].
Android apps. An app lists the CAs it trusts in its network security configuration. Android's documentation names a host with a custom CA, such as one issued internally within a company, as a reason for it ^[4].
Firefox. The ImportEnterpriseRoots enterprise policy makes Firefox trust certificates that a user or administrator added to the operating system certificate store ^[5].
Servers and command-line tools. Hand the tool the root file. OpenSSL takes it through the -CAfile option ^[6].

Test trust before rollout. This command checks a server certificate against your root and the intermediate between them:

openssl verify -CAfile root.pem -untrusted intermediate.pem server.pem

The -untrusted option supplies intermediates that are not trust anchors ^[6].

Limit what the CA can sign

A private CA has the same shape as a public CA: a root that stays off the daily path, and an intermediate certificate that signs server certificates. The root signs the intermediate once and then stays offline. The intermediate does the daily work.

Put the limit in the intermediate. A name constraint is an extension in a CA certificate that confines every certificate below it to a name space, and a conforming CA must mark it critical ^[2]. If the constraint lists only your own domain names, a client that enforces it rejects a DNS name outside them, even on a certificate from a stolen intermediate. Enforcement is the client's behaviour, so test each client you support.

What a leaked root key costs

A device that trusts your root accepts any valid chain that leads to it. If the CA private key leaks and nothing constrains the root, whoever holds the key can issue a certificate for any name those devices will accept. That includes the names of public sites.

Recovery falls on you. You revoke what was issued, replace the CA and put the new root on every device, because no outside party removes your root from your devices. Revocation is also your job in ordinary operation. A certificate can carry a pointer to where its status is published, in the CRL distribution points extension ^[2], and your CA has to keep that location answering. How the pointers work is on the revocation page.

Set up a private CA in seven steps

A private CA is a private PKI in small: a root, an intermediate and the rules that govern them. It does not replace a public CA on a site that visitors reach, and the steps below assume you run the certificate authority yourself.

Decide the name space the CA will cover and which devices will trust it.
Create the root key and a self-signed root certificate. With OpenSSL that is openssl req -x509 -new ^[7]. Keep the key off any machine that issues certificates day to day.
Create the intermediate certificate, with a name constraint, signed by the root.
Issue server certificates from the intermediate. OpenSSL's manual calls openssl ca a sample minimal CA application ^[8]. It is enough to learn on. For a CA you intend to keep running, look at software built to operate one: a managed cloud service or self-hosted CA software.
Install the root on every device that must trust it, as in the list above.
Publish revocation information at the address the certificates point to.
Verify with the command above, from a device that has only the root installed.

FAQ

What is a private CA?

A private CA, or private certificate authority, is a certificate authority whose root you distribute yourself. Its certificates are trusted only on devices where that root is installed. A public CA's root, by contrast, ships as a trust anchor in widely-available application software.

What is the difference between a public CA and a private CA?

Trust. A public CA's root is already in browsers and operating systems, so any visitor accepts its certificates. A private CA's root is not, so you install it yourself on each device. The table above compares names, trust and accountability.

When should I use a private CA?

Use a private CA for internal hostnames and reserved IP addresses, which a certificate authority that follows the Baseline Requirements may not certify, and for services reached only from devices you control. Use a public CA for anything a visitor's browser has to accept without setup.

How do I set up a private CA?

A private CA starts with a root, then a name-constrained intermediate, then server certificates. After that you install the root on your devices and publish revocation information. Unlike a public CA, you also run the certificate authority yourself. The seven steps above give the order, and OpenSSL's own manual describes its ca command as a sample minimal CA application.

Sources

CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, section 1.6.1 definitions and section 4.2.2.
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile: section 4.2.1.10 Name Constraints, section 4.2.1.13 CRL Distribution Points, section 6.1.1 Inputs to path validation.
Apple Support, Trust manually installed certificate profiles in iOS, iPadOS, and visionOS, support.apple.com/en-us/102390.
Android Developers, Network security configuration, developer.android.com/privacy-and-security/security-config.
Mozilla, Enterprise policy templates for Firefox, Certificates, ImportEnterpriseRoots, mozilla.github.io/policy-templates.
OpenSSL 3.0 manual, openssl-verify and openssl-verification-options: the -CAfile and -untrusted options.
OpenSSL 3.0 manual, openssl-req: the -x509 and -new options, docs.openssl.org/3.0/man1/openssl-req/.
OpenSSL 3.0 manual, openssl-ca: sample minimal CA application, docs.openssl.org/3.0/man1/openssl-ca/.