(3 votes, average: 5.00 out of 5)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

December 15, 2021 1

PKI Architecture: Fundamentals of Designing a Private PKI System

in Hashing Out Cyber Security

We’ll break down everything you need to know about public key infrastructure architectures and what they look like with examples of different PKI architecture diagrams and visuals

Public key infrastructure, or PKI, is the (often unsung) hero of internet security. It’s the underlying framework that makes secure internet communications a reality through the use of public key encryption. Today we’re going to talk specifically about PKI architecture — the systems, servers, and other stuff that you need (most of which is found behind the scenes) — to harness the power of PKI for your business.

PKI architecture exists in multiple forms depending on what you’re doing with PKI:

• Publicly Trusted PKI. If you want your digital certificates to always be recognized and publicly trusted by clients and operating systems in public channels (i.e., on the internet), you’ll need to use digital certificates that are issued by a publicly trusted certificate authority. In this scenario, the PKI architecture is fully run by the certificate authority (i.e., you just put their certificates to work to secure public-facing resources), but we’ll still go over the basics if you’re curious.
• Privately Trusted PKI. If you’re using PKI to secure internal assets or networks, then running a private CA might be the best option. In this scenario, you’ll need to make your own decisions about the PKI architecture — we’ll go over the basics of what you need to know in this article.

What do these PKI architectures look like? And what other types of PKI architectures can you use? In this article, we’ll define what PKI architecture is and go over some of the different types of architectures organizations adopt. These PKI architecture examples will include detailed PKI architecture diagrams and other visuals that show their different components and how they tie together.

Let’s hash it out.

What Is PKI Architecture? A Definition of PKI Architecture

PKI architecture describes all of the organizational and structural components that make it possible to create, use, and manage your organization’s public key infrastructure. This includes everything from servers and HSMs that host the CA to components of the CA such as root certificates and CRLs.

This article will present two key aspects of PKI architecture:

• The main components of a PKI system in general, and
• What you need to know about the IT and server architecture that’s needed to run a private CA.

Back in the 90s, The Open Group (a global consortium that develops technology standards and certifications) tried its hand at breaking down PKI architecture into groups of components. These eight broad categories encompass everything from security services and protocols to key management and policy services.

We aren’t going to get more into it beyond that because that’ll lead us down another rabbit hole. So, if you want to learn more about The Open Group’s component categories, check out the link I added in the paragraph above.

To really understand PKI architecture for the purpose of this article, there are certain concepts and terms that you need to know — the chief of which is public key infrastructure. So, before we move on to breaking down the different types of PKI architectures, let’s first quickly re-hash what “public key infrastructure” means.

What Is PKI? A 2-Minute Review of a Few Key Concepts

Now, we’ve already written several in-depth articles that explain what public key infrastructure is and how PKI works. But we’ll quickly review some of these components before moving on to give you various examples of PKI architecture.

A quick definition of public key infrastructure entails everything that makes secure communications possible on the internet. It’s the underlying technologies (including digital certificates and cryptographic keys), policies, processes that:

• Allow customers to make purchases on your website without fear that their information will get stolen in transit,
• Enable your employees to communicate securely and send sensitive information via email, and
• Help you secure your online services, internal sites, and other digital resources from unauthorized access.

Prior to the creation of encryption (which dates back to at least the ancient Egyptians), two parties had to physically meet up to exchange identical keys to exchange encrypted communications. But in a global digital world that enables data to travel at the speed of light, that kind of antiquated approach to key exchange is no longer necessary. This is where public key infrastructure comes into play.  

The 3 Main Elements of Public Key Infrastructure

1. Digital certificates. These are small digital files that enable identity and encryption for a variety of use cases on the internet. Each certificate contains a wealth of identifying information about the organization or entity it’s issued to (depending on the validation level it’s issued with) but has a finite lifespan. Common digital certificate categories include:
   1. SSL/TLS certificates — These certificates are what make the secure padlock icons appear in your website visitors’ browsers and the “not secure” warnings disappear. SSL/TLS certificates come with three validation level options — domain validation (DV), organization validation (OV), and extended validation (EV).
   2. Code signing certificates —These digital certificates help you secure your supply chain for software updates and offer users assurance that your software is legitimate and hasn’t been tampered with. Code signing certificates come with one of two validation levels — standard or extended validation — and the latter makes Windows Defender SmartScreen warnings disappear because they make your software automatically trusted by Windows operating systems and browsers!
   3. Document signing certificates — These digital certificates use cryptographic functions (hashing) and digital signatures allow you to prove to users that your document is legitimate and hasn’t been altered since you signed it.
   4. Email signing certificates — These digital certificates, also known as S/MIME certificates, provide end-to-end encryption by encrypting your email content and attachments prior to them leaving your inbox. Email signing certificates also provide digital identity by allowing you to digitally sign your messages so that your recipients can verify that the information hasn’t been altered and that it was actually you who sent it.
   5. Client authentication certificates — These digital certificates enable passwordless authentication on your internal network. What this means is that authorized users can log in securely and verify their identities without having to remember or type in a cumbersome password and complete multi-factor authentication.
2. Public-private cryptographic key pairs. These are the cryptographic tools you need to encrypt (public key) and decrypt (private key) information over the internet.
   1. Public key — This key encrypts data to prevent unauthorized access.
   2. Private key — This key decrypts data and is kept secret by the owner of the associated certificate.
3. Certification authorities. One of the key components of any PKI architecture is a certification authority, or what’s more commonly called a certificate authority or CA. An organization can rely on one or more CAs within its PKI. When people think of a CA, they traditionally think of it in the sense of a root CA or an issuing CA. However, there are also intermediate CAs as well. Here’s a quick description of each to help you differentiate between the three of them:
   1. Root CAs: A root CA depends on a root certificate, which must added to the trust store on every device that will be using the certificates you plan to issue for it to be trusted. Both public and private CAs have root CAs and certificates. Because all certificates tie back to these root certificates, CAs do everything within their power to keep their corresponding private keys secure. This typically involves storing root CA private keys offline in secure environments and by using hardware security modules (HSMs).
   2. Intermediate CAs: This type of CA serves as one or more links in the certificate chain and is digitally signed/issued by the root CA. They’re responsible for issuing endpoint certificates (like SSL/TLS certificates that you use to secure websites) to your organization. Essentially, intermediate CAs serve as the middleman between endpoint certificates and the root certificates they eventually chain back to.
   3. Issuing CAs: Sometimes, intermediate CAs and issuing CAs are one in the same and sometimes they’re separate. The difference depends on your CA hierarchy and how many tiers you have in your PKI architecture. (Read on to understand what we mean when we talk about PKI architecture tiers…)

The Term PKI Architecture Can Refer to Public or Private PKI

PKI can be a tough topic to wrap your brain around because some terms are commonly used in multiple contexts:

1. Public PKI (Public CA) — This term refers to a PKI that issues certificates that are automatically trusted by most browsers and devices. For example, if you purchase an SSL certificate from The SSL Store, that certificate is issued by a public CA. This is the most commonly used type of PKI.
2. Private PKI (Private CA) — This refers to PKI that is only used to secure your internal network. The certificates won’t be automatically trusted on all devices — you’ll need to install the appropriate root certificate on each device first. The plus side is that you have a lot more control over the certificates you issue. Private PKI can be set up via tools like Microsoft CA or via managed PKI services (aka mPKI or PKI as a service).

We’ll explore all three approaches more in-depth later in this article:

1. Public CA
2. Private CA (DIY)
3. Private CA (mPKI)

The #1 Rule of PKI: You Do Not Talk About Your Private Key

One of the most important things you need to do when designing, implementing, and managing a PKI is: protect your private keys at all costs. For example, if your root certificate’s private key is comprised, you’re screwed. Every single certificate you ever issued from it would have to be revoked. You’d essentially have to blow up your whole PKI and start over fresh.

That’s why a lot of the best practices and advice you’ll see about PKI architecture emphasize isolating and protecting your private keys, especially your root and intermediate certificates’ keys. Let’s dive in by looking at the hierarchies used to isolate root certificate private keys from the public…

One-, Two and Three-Tier Trust Hierarchies in PKI Architecture

PKI architectures can come in a couple of different formats in terms of their hierarchies of trust — the structure that each company uses depends on its needs. Trust hierarchies can range from one-tier to three-tier architectures.

Three-tier architectures offer the greatest level of protection for your root CA private keys and scalability in terms of certificate issuance. However, two-tier hierarchies are typically enough for most organizations’ needs.

First, let’s look at an example of what a basic one-tier hierarchy looks like:

In most cases, you shouldn’t use a one-tier hierarchy because it doesn’t allow you to protect your root certificate’s private key as well. Now, let’s look at a two-tier PKI architecture:

Now, compare this to the structure of a three-tier CA:

See the difference? The two- and three-tier architectures provide buffers between the root CAs and the leaf certificates that are issued to organizations. Because leaf certificates aren’t issued directly from the root CA, these degrees of separation help to keep the root CA private key secure from compromise.

Why Having Separation Between Your Root CA and Leaf Certificates Is a Good Thing…

There’s a game called the Six Degrees of Kevin Bacon. The idea is that any actor in Hollywood can be connected to the actor Kevin Bacon by six (or fewer) introductions — the person who can tie that actor with the fewest degrees of separation wins. PKI architecture takes the opposite approach — the more levels of separation between your root CA and the leaf certificates you use, the better (i.e., the more secure your PKI architecture is).

If an issuing CA’s key gets compromised, only the certificates issued by that CA must be revoked. But if a root CA’s key gets compromised, it means that every certificate ever issued by it (or issued by intermediate or issuing CAs that stem from that root) must be revoked. So, by signing your leaf certificates with an issuing CA’s private key rather than the root’s key, you significantly reduce the number of affected certificates in the unlikely event that the CA’s key gets compromised.

Now that we know what a PKI architecture is and the types of hierarchies that companies can use, let’s explore several examples of common PKI architectures and how they’re structured. If you haven’t yet had your morning cup of joe, you might want to grab a mug now — things are about to get heavy.

3 Examples of PKI Architecture (Uses and Diagrams)

This section will explore each of these PKI architectures more in-depth and provide a diagram of each as a visual representation.

PKI Architecture #1: Public CA

When most people think of PKI architecture, their minds automatically go to public CAs. This includes companies like DigiCert, Sectigo, Entrust, and hundreds of others globally. However, the overwhelming majority of certificates are issued by a half dozen or so leading CAs.

Public certificate authorities are publicly trusted because they adhere to specific industry rules and requirements. As such, they’re able to issue certificates that are also publicly trusted by operating systems, browsers, and mobile devices.

The way it all works is like this:

• You (the PKI admin) request your public CA certificates for your website, endpoint devices, etc. from the public CA.
• All of the “magic” happens within the CA’s environment — they use their resources and personnel to validate your domain and/or organizational details.
• Once the public CA verifies your organizational information, they issue publicly trusted certificates that meet industry standards and requirements.
• Once the public CA issues the certificates, you must use your internal resources/personnel and follow internal policies to deploy the certificates across your public network.

Here’s a quick graphic that gives you a basic visual of what this process looks like:

But what does a public CA’s PKI architecture actually look like? The CAs don’t like to disclose all the details of their architectures, but the following basic flowchart should give you a pretty basic idea of what it entails and how you interact with it:

Just keep in mind that within that “Public CA’s Secure Facility” bubble, that the PKI architecture itself is typically a two-tier CA model, although some certificate authorities opt for three-tier — the latter is just less common.

While publicly trusted certificates are important and serve many uses, they can’t meet all of your organization’s security needs. After all, you have private network devices and apps you also need to secure, right? This is why many enterprises and organizations opt to create something known as a private PKI or a private CA.

PKI Architecture #2: Private CA (Internal CA)

Private PKI, private CA, internal PKI, or internal CA — these are all different terms that describe the same thing. So, whatever you want to call it, private PKI boils down to having the PKI structure in place to secure your websites, services, devices, and other IT resources on your network.

Want to issue private user authentication certificates that will be trusted within your network? Check. How about securing your virtual private network (VPN) access? Also check. IoT devices? Employee ID cards? Containerized environments? Check, check, check. At the risk of sounding like a late-night infomercial host, private PKI can be virtually everything you want it to be — you know, at least as far as securing your internal network and IT infrastructure goes.

So, what does a private PKI architecture look like? Here’s a basic overview of what all of that entails:

You Can Set Up a Private CA Using Microsoft CA and AWS

Running your own private CA checks many of the boxes that companies care about when it comes to IT and security and user management, and it gives you the greatest control of your PKI. You could use a resource like Microsoft CA, or what’s technically known as Active Directory Certificate Services (ADCS), to set up and manage your private PKI.

You can host your PKI on-prem or use a cloud-hosting provider such as Amazon Web Services (AWS) to host your Microsoft CA deployment, deploying your root and subordinate private CAs on Windows servers and using AWS Cloud HSM to sign your certs and store your private keys. This means you don’t have to go to the trouble and expense of setting up your own HSMs on-prem.

Let’s take a quick peek at how it looks when you set up your private PKI via AWS:

For a closer look at the virtual private cloud (VPC) that is highlighted with the green box in the lower-right quadrant of the image and how that would look if you decided to go the cloud or hybrid PKI route, check out the following graphic:

It’s important to note that the above PKI architectural graphic is really part of a quick start guide that doesn’t include recommended components such as an HSM. A true private PKI is more complicated, but this should at least help provide a basic idea of the architecture.

The Challenges of Setting Up Your Own Private PKI

But there is one huge caveat about running a private PKI: you have to have the budget, infrastructure, time, money, and skilled people to dedicate to it. As you can imagine, setting up and managing a private PKI costs way more than an infomercial’s magic price of $19.99. Properly managing your PKI takes a lot of time, labor, and resources for organizations of all sizes.

• Understaffing is a huge issue — data from Keyfactor and the Ponemon Institute’s State of Machine Identity Management Report 2021 shows that only 45% of companies say they have staff dedicated to managing their PKI.
• Many in-house teams don’t know how to securely manage a certificate authority because they don’t necessarily handle those responsibilities in their day-to-day jobs.

For these reasons (among others), many organizations that want to have their own PKIs wind up hiring managed PKI providers to handle setting one up and managing it for them.

PKI Architecture #3: Managed PKI (mPKI or PKI-as-a-Service)

Remember the 2009 phrase “There’s an App for That”? Well, the same can be said for the security services that you can outsource to experienced third-party providers, including the day-to-day management of your organization’s public key infrastructure. This is where a managed PKI service provider can make your work life a whole lot easier.

Several reputable CAs and PKI vendors offer what’s known within the industry as “PKI-as-a-service.” An mPKI provider is a third party that handles everything from setting up and rolling out your organization’s private CA to supporting it in the long run. They use their internal resources to facilitate this process.

Because this is what they eat, sleep, and breathe PKI all day, every day, they’re intimately familiar with all of the ins-and-outs of PKI that your team is unlikely to know or think about. They’re also very familiar with many of the issues you might face when setting up your PKI — and they have processes, procedures and policies in place to help mitigate them. 

But what does this look like in terms of PKI architecture? We’re glad you asked. Let’s take the basic private PKI architecture graphic we shared earlier and update it to reflect changes relating to managed PKI:

As your organization’s PKI administrator, as you can see, many of the typical responsibilities and monotonous tasks no longer fall squarely on your shoulders when you work with an mPKI provider. Instead, there are only select things that you’ll be partially or fully responsible for implementing and managing — your mPKI partner handles the rest. This means you don’t have to worry about having to know everything yourself or hiring someone to fill specific skills gaps. You can just lean on the mPKI professionals to take care of most things for you.

However, you still have full control over the things that matter to your organization, such as certificate profiles and validation requirements.

No Matter What Type of PKI Architecture You Have, You Need to Manage Your Certificates and Keys Carefully…

Now, there’s a really important sidenote we have to at least mention here: the effectiveness of your PKI depends on how well you manage your certificate and key lifecycle. The lifecycle encompasses everything from creating and managing certificates (and their corresponding keys) to those certificates’ reissuances or (infrequent) revocations.

This responsibility is a deciding factor in your organization’s security and compliance capabilities. As such, staying on top of your PKI’s certificate and key lifecycles is crucial in many ways. If even just one certificate expires on a public-facing system, or if a single private key gets compromised, you’ll be in for a world of hurt — you just might not know it right away…

Let’s consider what happened to Equifax back in 2017. Unbeknownst to Equifax’s IT security team, one of their digital certificates expired and they didn’t realize it until many months later. This led to a data breach that went undetected for two-and-a-half months and, ultimately, resulted in massive fines and settlement payments that the company is expected to pay.

Thankfully, there are some steps you can take to avoid many of these PKI management-related issues.

Use an HSM to Securely Store Your CA Private Keys

These are the secure storage devices that help your organization keep your private keys safe. You can use an offline hardware security module (HSM) to store your root CA keys and an online HSM to store your intermediate CA keys for private PKI. But if you don’t want to go through the hassle of buying and setting up HSMs to use within your environment, a better option might be to use a managed PKI platform that’s built using HSMs.

Use a PKI Management Tool to Manage Your Certificates and Keys

If you only have a handful of certificates and keys to track and manage, you can likely get away with using a spreadsheet to manage your PKI. But considering that another report from Keyfactor and the Ponemon Institute shows that organizations have an average of 88,750 certificates and keys in use on their networks, it’s impossible for full-time PKI admins to keep track of them all using manual means. This is why companies often use certificate management platforms to help them stay on top of their certificates, so nothing falls through the cracks.

Final Thoughts on PKI Architecture

There’s clearly a lot to know when it comes to understanding and differentiating between each different PKI architecture and they’re individually structured. We hope this article has provided you with some useful insights about how PKI architectures are designed and how they can be used to secure your organization’s external and internal assets.

We included many resources relating to PKI and certificate authorities throughout the article. However, here are some additional related resources that you may find useful:

• How to Become a Certificate Authority (Public vs Private)
• Creating Your Own Certificate Authority Server
• The Difference Between Root Certificates and Intermediate Certificates

• #mPKI
• #PKI
• #PKI Architecture
• #Private PKI