If you recall from my earlier post, the world is full of PKIs. On one extreme, there are a great many private PKIs used by only one organization. On the other, there are a handful of public PKIs used by millions of organizations and billions of people.

The decision which to use—private or public—is often straightforward. If you need to protect a resource that needs to be accessed by other organizations, then chances are that only a public PKI will do. However, the opposite is not always true. If you have an entirely internal resource, you don't have to use a private PKI. Very often, a public PKI will do the job just fine, even though it's not intended for this use case.

There are upsides and downsides to choosing to use public PKI for your private networks, and you should be aware of them before you build too much of your architecture on an aspect that's not under your control.

For many, the decision to extend a public PKI for internal usage comes naturally. One day you are getting certificates for your public properties, then you create an internal web site that also needs protection. It's a very small step from there to using the same type of certificate as everywhere else.

That is fine. Using public PKIs in this way is extremely cost-effective, as you're getting access to significant resources operated by dozens of public CAs, at little or no cost. The main disadvantage is that you have to play by the rules of this ecosystem. In a nutshell:

• Public certificates are public; it may come as a surprise, but the vast majority of public certificates are automatically published for the entire world to consume. This system is called Certificate Transparency (CT); it's designed to improve security for everyone through radical transparency.
• Be wary of rate limits; perhaps this is not something you need to worry about if you're paying for your certificates, but free CAs have their limits. Small-time use of public certificates will fly under the radar, but significant projects (e.g., IoT) will most definitely hit the limits, and you may suddenly find yourself with your issuance broken.
• Authentication is weak; public PKIs are designed for everyone to participate in. To make this work, the system opted for implicit authentication based on proof of infrastructure control. Furthermore, public CAs don't need your consent before they put your names in their certificates. Although they mostly behave as they should, misissuances do happen.
• You have to adapt to the rules as they change; public PKIs are massive and continuously change to reduce the attack surface and improve security. For example, at the time of writing (early March 2026), a significant reduction of allowed maximum certificate lifetimes is about to begin. From 398 days today, certificates are expected to shrink to only 47 days in 2029. Another big change was dropping client certificates from Web PKI, which tripped a lot of companies using public certificates internally.
• Validation can be a pain; the dominant certificate validation method in use today is based on proof of infrastructure control. That means, if you want a certificate for google.com, you have to be able to make a change to the website at that address. This gets complicated when your infrastructure is private; CAs don't have access to complete their checks. To make things worse, these days CAs operate something known as Multi-Perspective Issuance Control (MPIC), which means that they have to validate from multiple geographical locations in order to prevent routing attacks. Are there ways to resolve these problems? Yes, there are. You won't be able to just use the defaults but, after jumping through some hoops, you'll get it done. In fact, it's about to get easier with the new DNS-PERSIST-01 validation method.

The best thing about doing it yourself is this: it's your PKI, it's your rules. If you don't believe in short certificate lifetimes but you believe in reliable revocation checking, the good news is that you can make it happen. You have all the tools as everyone else, including some of the software used by the public CAs for issuance. Go crazy and build exactly what you need.

The downside is that you have to do everything by yourself. This is expensive; you need expertise, time, and money. It's become less expensive in recent years, as there are now many vendors who offer PKI-as-a service, or PKIaaS.

A big advantage of having control over your PKI is that you can move at whatever speed you wish. Traditionally, this has been a disadvantage. Public PKIs did a great job deprecating obsolete and weak cryptography, an area where many private PKIs seriously lagged.

But, when speed is of the essence, public PKIs can be slow. Take, for example, the fact that when the world is in the midst of a transition to post-quantum cryptography. In your own private PKI you could, today, deploy certificates based around quantum-safe algorithms. These certificates are still out of reach of public PKIs.