In our first interview with Darin Andrew, Senior PKI Architect at DigiCert, we learned to keep the next 5–10 years in mind when making decisions about PKI architecture. We even learned about three ways top enterprises are using PKI to enhance cybersecurity.

Now, we ask Darin about the difference between public and private PKI, which is best for different use cases, and how some of the top enterprises have built PKIs that scale successfully. We start from square one—discussing the purpose of a root certificate.

What’s a root certificate?

DA: Public Key Infrastructure (PKI) is binding an identity to the public key through a signing process.

That signature is performed by a root (or with an intermediate that chains up to the root). That’s how you identify if a certificate is valid, and whether you want to trust it.

If you possess the public key of the root that signed the certificate, then you can know that the identity bound to the public key is valid and can be trusted. This is all because the certificate was issued by the root.

What’s a public root?

DA: The technology used for signing a certificate is the same whether signing with a private or public root. We’re not changing the cryptography or the signature. We’re simply saying that a publicly trusted root is already distributed out to browsers, operating systems, phones, etc. Browsers, like Chrome and Firefox, have root stores where they keep a list of the roots they trust.

A private root differs from a public root because private roots aren’t already distributed to the trust stores of major browsers and operating systems. A private root is created by a company or a CA, and won’t be included in the list Google and Mozilla have in their browser trust stores.

It’s a private root because it’s trusted by whatever systems the company wants to distribute that root to internally. They can distribute that root to their servers or a select number of their servers, phones, desktops, and laptops. They can issue certificates from that private root that will be trusted by whichever system they deliver that root to for checking if certificates are valid.

Because the technology behind public and private roots is the same—the certificate looks the same and the same signature hash algorithm can be used to sign the certificate—the next question would be, when do you use a private root versus a public root?

When should you use a public root versus a private root?

DA: A private root is useful for internal operations. However, when you’re talking about a public-facing web page, you need a certificate issued from a public root.

Think about your website. When users visit your site, does their browser possess the root? With a private root, the answer depends on whether it’s being accessed from a computer the organization manages or not.

The browser can have the private root if you’ve distributed your private root to that device. If the certificate has been issued by a private root that has been added to the browser’s trust store, the browser will trust it when it connects to the web page.

But what happens if this is a public web page that anyone in the world can hit? Unless you’ve distributed your private root to every single device that’s used to visit the page (which isn’t possible), users will receive a warning message saying the root that issued the certificate isn’t trusted.

Browsers are giving severe warning messages these days. Either the users won’t be able to visit the page, or they’ll be forced to change their settings to make the connection. That’s not a good place to be in.

How would the private/public root scenario influence something like email signing?

DA: If you’re sending email to someone within your own company, you sign your email using a certificate issued from the private root—that works. The recipient checks the signature, sees it was issued by the private root that’s already on their computer, and they say, "That certificate is valid."

But, what happens when you send that email to someone from another organization that doesn’t have your private root? They’ll see a message that says the signature is not valid.

This automatically happens in Outlook, for example. Outlook checks to see if the root that issued the certificate is in the root store of the operating system. When it sees that it’s not, Outlook displays a message saying that the signature is not valid.

Using a private root for email doesn’t make much sense. The reason you sign email is to assure the person on the other end that they can trust that the message was sent from you and wasn’t altered.

But, when you send email to another organization (which is the nature of email), if you’re using a private root, this results in an untrusted message. You’ve now destroyed the purpose for signing the email. This is an instance where you need publicly trusted certificates issued from a public root.

In short, a private root will help you secure internal operations. But when you’re sharing information with entities outside your organization—like signing an email—you need a public root that’s distributed to browsers and operating systems.

So, in what scenarios would a private root be useful?

DA: Authentication of internal services is a strong use case for private roots. For example, a private root is useful for authenticating connections into your virtual private network (VPN), internal Wi-Fi, wiki pages, or other services that support multi-factor authentication.

In all those cases, you control the server instance that’s checking the validity of the certificate, so a private root will work great. Your internal operations team can specify your own private root as the issuer of certificates, and when validity is being checked, it can see that it was issued by your own private root.

Using a private root has its benefits over public roots. If it’s a dedicated private root for your organization, only your team can issue certificates off that root. No one else can issue certificates off that private root. Certificates issued from a private root have more flexibility for certificate profiles and subjects named in the certificates.

The benefits of a private root for authentication boil down to control. If you have a private root that’s dedicated to you, you have more control over the issuance process, certificate profiles, and subjects named in the certificates. Because you have more control, you know with more certainty that you’re the only one who has the rights to issue certs from it.

Do most enterprises have a public or private PKI?

DA: It’s most common for enterprises to use a hybrid of the two. For example, a company might use a public CA to issue certificates for its public-facing website. Then, for authenticating connections to its internal services—like a VPN or wiki—that same company might set up a private root where they can issue certificates.

Let’s say I’ve decided to set up a hybrid PKI solution—what’s next?

DA: Next, you’ll want to decide whether you use a hosted solution for your private PKI, or build your own internal CA.

Often, people think public PKI is hosted and private PKI is not hosted—this isn’t the case. Public and private PKI can both be hosted. The question is whether you have an internal CA or use a hosted CA for your private PKI.

In our next interview with Darin, we’ll dive into the considerations of whether to use a hosted or internal CA solution. For now, here are your takeaways for making decisions between public and private PKI: