PKI architecture exists in multiple forms depending on what you\u2019re doing with PKI:<\/p>\n\n\n\n
- \n
- Publicly Trusted PKI.<\/strong> 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\u2019ll 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\u2019ll still go over the basics if you\u2019re curious.<\/li>\n\n\n\n
- Privately Trusted PKI.<\/strong> If you\u2019re using PKI to secure internal assets or networks, then running a private CA might be the best option. In this scenario, you\u2019ll need to make your own decisions about the PKI architecture \u2014 we\u2019ll go over the basics of what you need to know in this article.<\/li>\n<\/ul>\n\n\n\n
What do these PKI architectures look like? And what other types of PKI architectures can you use? In this article, we\u2019ll 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.<\/p>\n\n\n\n
Let\u2019s hash it out.<\/span><\/p>\n\n\n<\/span><\/span>\n\n\n
What Is PKI Architecture? A Definition of PKI Architecture<\/h2>\n\n\n\n
PKI architecture describes all of the organizational and structural components that make it possible to create, use, and manage your organization\u2019s 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.<\/p>\n\n\n\n
This article will present two key aspects of PKI architecture:<\/p>\n\n\n\n
- \n
- The main components of a PKI system in general, and<\/li>\n\n\n\n
- What you need to know about the IT and server architecture that\u2019s needed to run a private CA.<\/li>\n<\/ul>\n\n\n\n
Back in the 90s, The Open Group<\/a> (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.<\/p>\n\n\n\n
We aren\u2019t going to get more into it beyond that because that\u2019ll lead us down another rabbit hole. So, if you want to learn more about The Open Group\u2019s component categories, check out the link I added in the paragraph above.<\/p>\n\n\n\n
To really understand PKI architecture for the purpose of this article, there are certain concepts and terms that you need to know \u2014 the chief of which is public key infrastructure. So, before we move on to breaking down the different types of PKI architectures, let\u2019s first quickly re-hash what \u201cpublic key infrastructure\u201d means.<\/p>\n\n\n\n
What Is PKI? A 2-Minute Review of a Few Key Concepts<\/h2>\n\n\n\n
Now, we\u2019ve already written several in-depth articles that explain what public key infrastructure is<\/a> and how PKI works<\/a>. But we\u2019ll quickly review some of these components before moving on to give you various examples of PKI architecture.<\/p>\n\n\n\n
A quick definition of public key infrastructure entails everything that makes secure communications possible on the internet. It\u2019s the underlying technologies (including digital certificates and cryptographic keys), policies, processes that:<\/p>\n\n\n\n
- \n
- Allow customers to make purchases on your website without fear that their information will get stolen in transit,<\/li>\n\n\n\n
- Enable your employees to communicate securely and send sensitive information via email, and<\/li>\n\n\n\n
- Help you secure your online services, internal sites, and other digital resources from unauthorized access.<\/li>\n<\/ul>\n\n\n\n
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. <\/p>\n\n\n\n
The 3 Main Elements of Public Key Infrastructure<\/h3>\n\n\n\n
- \n
- Digital certificates.<\/strong> 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\u2019s issued to (depending on the validation level it\u2019s issued with) but has a finite lifespan. Common digital certificate categories include:\n
- \n
- SSL\/TLS certificates<\/strong> \u2014 These certificates are what make the secure padlock icons appear in your website visitors\u2019 browsers and the \u201cnot secure\u201d warnings disappear. SSL\/TLS certificates<\/a> come with three validation level options \u2014 domain validation (DV), organization validation (OV), and extended validation (EV).<\/li>\n\n\n\n
- Code signing certificates<\/strong> \u2014These digital certificates help you secure your supply chain for software updates and offer users assurance that your software is legitimate and hasn\u2019t been tampered with. Code signing certificates<\/a> come with one of two validation levels \u2014 standard or extended validation \u2014 and the latter makes Windows Defender SmartScreen warnings disappear because they make your software automatically trusted by Windows operating systems and browsers!<\/li>\n\n\n\n
- Document signing certificates<\/strong> \u2014 These digital certificates use cryptographic functions (hashing) and digital signatures allow you to prove to users that your document is legitimate and hasn\u2019t been altered since you signed it.<\/li>\n\n\n\n
- Email signing certificates<\/strong> \u2014 These digital certificates, also known as S\/MIME<\/a> certificates, provide end-to-end encryption by encrypting your email content and attachments prior to them leaving your inbox. Email signing certificates<\/a> also provide digital identity by allowing you to digitally sign your messages so that your recipients can verify that the information hasn\u2019t been altered and that it was actually you who sent it.<\/li>\n\n\n\n
- Client authentication certificates<\/strong> \u2014 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.<\/li>\n<\/ol>\n<\/li>\n\n\n\n
- Public-private cryptographic key pairs.<\/strong> These are the cryptographic tools you need to encrypt (public key) and decrypt (private key) information over the internet.\n
- \n
- Public key<\/strong> \u2014 This key encrypts data to prevent unauthorized access.<\/li>\n\n\n\n
- Private key<\/strong> \u2014 This key decrypts data and is kept secret by the owner of the associated certificate.<\/li>\n<\/ol>\n<\/li>\n\n\n\n
- Certification authorities.<\/strong> One of the key components of any PKI architecture is a certification authority<\/a>, or what\u2019s 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\u2019s a quick description of each to help you differentiate between the three of them:\n
- \n
- Root CAs:<\/strong> 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).<\/li>\n\n\n\n
- Intermediate CAs:<\/strong> This type of CA serves as one or more links in the certificate chain and is digitally signed\/issued by the root CA. They\u2019re 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.<\/li>\n\n\n\n
- Issuing CAs: <\/strong>Sometimes, intermediate CAs and issuing CAs are one in the same and sometimes they\u2019re 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\u2026)<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n\n\n\n
The Term PKI Architecture Can Refer to Public or Private PKI<\/h3>\n\n\n\n
PKI can be a tough topic to wrap your brain around because some terms are commonly used in multiple contexts:<\/p>\n\n\n\n
- \n
- Public PKI (Public CA)<\/strong> \u2014 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.<\/li>\n\n\n\n
- Private PKI (Private CA)<\/strong> \u2014 This refers to PKI that is only used to secure your internal network. The certificates won\u2019t be automatically trusted on all devices \u2014 you\u2019ll 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<\/a>).<\/li>\n<\/ol>\n\n\n\n
![\"A](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/public-vs-private-pki-comparison.png\")
As a PKI administrator, you can use a public CA (left column) to issue digital certificates that secure your endpoints, website and other resources on the internet. You also can use a private CA to issue certificates and keys that secure sensitive resources and devices on your internal network. <\/figcaption><\/figure>\n\n\n\n We\u2019ll explore all three approaches more in-depth later in this article:<\/p>\n\n\n\n
- \n
- Public CA<\/li>\n\n\n\n
- Private CA (DIY)<\/li>\n\n\n\n
- Private CA (mPKI)<\/li>\n<\/ol>\n\n\n<\/span><\/span>\n\n\n
The #1 Rule of PKI: You Do Not Talk About Your Private Key<\/h2>\n\n\n\n
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\u2019s private key is comprised, you\u2019re screwed. Every single certificate you ever issued from it would have to be revoked. You\u2019d essentially have to blow up your whole PKI and start over fresh.<\/p>\n\n\n\n
That\u2019s why a lot of the best practices and advice you\u2019ll see about PKI architecture emphasize isolating and protecting your private keys, especially your root and intermediate certificates\u2019 keys. Let\u2019s dive in by looking at the hierarchies used to isolate root certificate private keys from the public\u2026<\/p>\n\n\n\n
One-, Two and Three-Tier Trust Hierarchies in PKI Architecture<\/h2>\n\n\n\n
PKI architectures can come in a couple of different formats in terms of their hierarchies of trust \u2014 the structure that each company uses depends on its needs. Trust hierarchies can range from one-tier to three-tier architectures.<\/p>\n\n\n\n
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\u2019 needs.<\/p>\n\n\n\n
First, let\u2019s look at an example of what a basic one-tier hierarchy looks like:<\/p>\n\n\n\n
![\"A](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/1-tier-CA-pki-architecture-diagram.png\")
In this PKI architecture diagram example, the online root CA doubles as the issuing CA because its root CA certificate issues the leaf certificates. <\/figcaption><\/figure>\n\n\n\n In most cases, you shouldn\u2019t use a one-tier hierarchy because it doesn\u2019t allow you to protect your root certificate\u2019s private key as well. Now, let\u2019s look at a two-tier PKI architecture:<\/p>\n\n\n\n
![\"A](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/2-tier-ca-pki-architecture-diagram.png\")
In this PKI architecture diagram example, the offline root CA certificate\u2019s private key signs the certificates of the issuing CA. The issuing CA is responsible for issuing leaf certificates that its private key signs. This provides a layer of separation between the root CA and the leaf certificates, which is denoted by the dotted line that separates offline vs online PKI architecture components. <\/figcaption><\/figure>\n\n\n\n Now, compare this to the structure of a three-tier CA:<\/p>\n\n\n\n
![\"A](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/3-tier-ca-pki-architecture-diagram-843x1024.png\")
In this PKI architecture diagram example, the offline root CA certificate\u2019s private key signs the certificates of the online intermediate CA. The intermediate CA then signs the certificates of the issuing CAs (which is also online) using their private keys. The issuing CAs are responsible for issuing leaf certificates using their private key signs. This provides multiple layers of separation between the root CA and the leaf certificates. Once again, the dotted line denotes the difference between online vs offline PKI architecture components. <\/figcaption><\/figure>\n\n\n\n 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\u2019t issued directly from the root CA, these degrees of separation help to keep the root CA private key secure from compromise.<\/p>\n\n\n\n
Why Having Separation Between Your Root CA and Leaf Certificates Is a Good Thing\u2026<\/h3>\n\n\n\n
There\u2019s a game called the Six Degrees of Kevin Bacon<\/a>. The idea is that any actor in Hollywood can be connected to the actor Kevin Bacon by six (or fewer) introductions \u2014 the person who can tie that actor with the fewest degrees of separation wins. PKI architecture takes the opposite approach \u2014 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).<\/p>\n\n\n\n
If an issuing CA\u2019s key gets compromised, only the certificates issued by that CA must be revoked. But if a root CA\u2019s 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\u2019s private key rather than the root\u2019s key, you significantly reduce the number of affected certificates in the unlikely event that the CA\u2019s key gets compromised.<\/p>\n\n\n\n
Now that we know what a PKI architecture is and the types of hierarchies that companies can use, let\u2019s explore several examples of common PKI architectures and how they\u2019re structured. If you haven\u2019t yet had your morning cup of joe, you might want to grab a mug now \u2014 things are about to get heavy.<\/p>\n\n\n\n
3 Examples of PKI Architecture (Uses and Diagrams)<\/h2>\n\n\n\n
PKI uses and applications<\/a> vary from one business to the next. This section will explore each of these PKI architectures more in-depth and provide a diagram of each as a visual representation.<\/p>\n\n\n\n
PKI Architecture #1: Public CA<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Public certificate authorities are publicly trusted because they adhere to specific industry rules and requirements. As such, they\u2019re able to issue certificates that are also publicly trusted by operating systems, browsers, and mobile devices.<\/p>\n\n\n\n
The way it all works is like this:<\/p>\n\n\n\n
- \n
- You (the PKI admin) request your public CA certificates for your website, endpoint devices, etc. from the public CA.<\/li>\n\n\n\n
- All of the \u201cmagic\u201d happens within the CA\u2019s environment \u2014 they use their resources and personnel to validate your domain and\/or organizational details.<\/li>\n\n\n\n
- Once the public CA verifies your organizational information, they issue publicly trusted certificates that meet industry standards and requirements.<\/li>\n\n\n\n
- 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.<\/li>\n<\/ul>\n\n\n\n
Here\u2019s a quick graphic that gives you a basic visual of what this process looks like:<\/p>\n\n\n\n
![\"What](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/pki-architecture-when-using-public-ca.png\")
<\/figure>\n\n\n\nBut what does a public CA\u2019s PKI architecture actually look like? The CAs don\u2019t 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:<\/p>\n\n\n\n
![\"A](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/public-certificate-authority.png\")
An illustration of public key infrastructure and where you as a PKI administrator and your public CA of choice fit into the process. Everything that is highlighted in the blue dotted lines occurs behind the scenes so you don\u2019t see it happening. <\/figcaption><\/figure>\n\n\n\n Just keep in mind that within that \u201cPublic CA\u2019s Secure Facility\u201d bubble, that the PKI architecture itself is typically a two-tier CA model, although some certificate authorities opt for three-tier \u2014 the latter is just less common.<\/p>\n\n\n\n
While publicly trusted certificates are important and serve many uses, they can\u2019t meet all of your organization\u2019s 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.<\/p>\n\n\n\n
PKI Architecture #2: Private CA (Internal CA)<\/h3>\n\n\n\n
Private PKI, private CA, internal PKI, or internal CA \u2014 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.<\/p>\n\n\n\n
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 \u2014 you know, at least as far as securing your internal network and IT infrastructure goes.<\/p>\n\n\n\n
So, what does a private PKI architecture look like? Here\u2019s a basic overview of what all of that entails:<\/p>\n\n\n\n
![\"A](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/private-pki-architecture.png\")
An general overview of how PKI architecture components can be categorized. <\/figcaption><\/figure>\n\n\n\n You Can Set Up a Private CA Using Microsoft CA and AWS<\/h4>\n\n\n\n
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\u2019s technically known as Active Directory Certificate Services (ADCS), to set up and manage your private PKI.<\/p>\n\n\n\n
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<\/a>, 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\u2019t have to go to the trouble and expense of setting up your own HSMs on-prem.<\/p>\n\n\n\n
Let\u2019s take a quick peek at how it looks when you set up your private PKI via AWS:<\/p>\n\n\n\n
![\"An](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/hybrid-pki-solution-aws.png\")
An overview of a hybrid PKI solution via AWS. Image source for this PKI architecture diagram: Amazon Web Services<\/a>. <\/figcaption><\/figure>\n\n\n\n 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:<\/p>\n\n\n\n
![\"An](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/microsoft-pki-aws-architecture-diagram-1024x546.png\")
A screenshot of AWS\u2019s Microsoft PKI diagram. Image source for this PKI architecture diagram: Amazon Web Services<\/a>. <\/figcaption><\/figure>\n\n\n\n It\u2019s important to note that the above PKI architectural graphic is really part of a quick start guide that doesn\u2019t 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.<\/p>\n\n\n\n
The Challenges of Setting Up Your Own Private PKI<\/h4>\n\n\n\n
But there is one huge<\/em> 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\u2019s magic price of $19.99. Properly managing your PKI takes a lot of time, labor, and resources for organizations of all sizes.<\/p>\n\n\n\n
- \n
- Understaffing is a huge issue \u2014 data from Keyfactor and the Ponemon Institute\u2019s State of Machine Identity Management Report 2021<\/a> shows that only 45% of companies say they have staff dedicated to managing their PKI.<\/li>\n\n\n\n
- Many in-house teams don\u2019t know how to securely manage a certificate authority because they don\u2019t necessarily handle those responsibilities in their day-to-day jobs.<\/li>\n<\/ul>\n\n\n\n
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.<\/p>\n\n\n<\/span><\/span>\n\n\n
PKI Architecture #3: Managed PKI (mPKI or PKI-as-a-Service)<\/h3>\n\n\n\n
Remember the 2009 phrase \u201cThere\u2019s an App for That\u201d? 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\u2019s public key infrastructure. This is where a managed PKI service provider can make your work life a whole lot easier.<\/p>\n\n\n\n
Several reputable CAs and PKI vendors offer what\u2019s known within the industry as \u201cPKI-as-a-service.\u201d An mPKI provider is a third party that handles everything from setting up and rolling out your organization\u2019s private CA to supporting it in the long run. They use their internal resources to facilitate this process.<\/p>\n\n\n\n
Because this is what they eat, sleep, and breathe PKI all day, every day, they\u2019re intimately familiar with all of the ins-and-outs of PKI that your team is unlikely to know or think about. They\u2019re also very familiar with many of the issues you might face when setting up your PKI \u2014 and they have processes, procedures and policies in place to help mitigate them. <\/p>\n\n\n\n
But what does this look like in terms of PKI architecture? We\u2019re glad you asked. Let\u2019s take the basic private PKI architecture graphic we shared earlier and update it to reflect changes relating to managed PKI:<\/p>\n\n\n\n
![\"A](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/mpki-pki-architecture.png\")
A basic illustrative PKI architecture diagram that showcases which responsibilities are areas your organization is responsible for versus your chosen mPKI provider.<\/figcaption><\/figure>\n\n\n\n As your organization\u2019s 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\u2019ll be partially or fully responsible for implementing and managing \u2014 your mPKI partner handles the rest. This means you don\u2019t 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.<\/p>\n\n\n\n
However, you still have full control over the things that matter to your organization, such as certificate profiles and validation requirements.<\/p>\n\n\n\n
No Matter What Type of PKI Architecture You Have, You Need to Manage Your Certificates and Keys Carefully\u2026<\/h2>\n\n\n\n
Now, there\u2019s a really <\/em>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\u2019 reissuances or (infrequent) revocations.<\/p>\n\n\n\n
This responsibility is a deciding factor in your organization\u2019s security and compliance capabilities. As such, staying on top of your PKI\u2019s 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\u2019ll be in for a world of hurt \u2014 you just might not know it right away\u2026<\/p>\n\n\n\n
Let\u2019s consider what happened to Equifax<\/a> back in 2017. Unbeknownst to Equifax\u2019s IT security team, one of their digital certificates expired and they didn\u2019t 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<\/a> and settlement payments<\/a> that the company is expected to pay.<\/p>\n\n\n\n
Thankfully, there are some steps you can take to avoid many of these PKI management-related issues.<\/p>\n\n\n<\/span><\/span>\n\n\n
Use an HSM to Securely Store Your CA Private Keys<\/h3>\n\n\n\n
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\u2019t 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\u2019s built using HSMs.<\/p>\n\n\n\n
Use a PKI Management Tool to Manage Your Certificates and Keys<\/h3>\n\n\n\n
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<\/a> shows that organizations have an average of 88,750 certificates and keys in use on their networks, it\u2019s 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.<\/p>\n\n\n\n
Final Thoughts on PKI Architecture<\/h2>\n\n\n\n
There\u2019s clearly a lot to know when it comes to understanding and differentiating between each different PKI architecture and they\u2019re 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\u2019s external and internal assets.<\/p>\n\n\n\n
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:<\/p>\n\n\n\n
- \n
- How to Become a Certificate Authority (Public vs Private)<\/a><\/li>\n\n\n\n
- Creating Your Own Certificate Authority Server<\/a><\/li>\n\n\n\n
- The Difference Between Root Certificates and Intermediate Certificates<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
We\u2019ll 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,…<\/p>\n","protected":false},"author":17,"featured_media":15290,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":"","tve_updated_post":"","tve_custom_css":"","tve_user_custom_css":"","tve_globals":{},"tcb2_ready":0,"tcb_editor_enabled":0,"tve_landing_page":"","_tve_header":"","_tve_footer":""},"categories":[16],"tags":[9900,228,13148,13149],"class_list":["post-15274","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hashing-out-cyber-security","tag-mpki","tag-pki","tag-pki-architecture","tag-private-pki","post-with-tags"],"views":30165,"jetpack_featured_media_url":"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/12\/pki-architecture-feature-image.jpg","_links":{"self":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/15274","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/users\/17"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/comments?post=15274"}],"version-history":[{"count":0,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/15274\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media\/15290"}],"wp:attachment":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media?parent=15274"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/categories?post=15274"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/tags?post=15274"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Creating Your Own Certificate Authority Server<\/a><\/li>\n\n\n\n
- Many in-house teams don\u2019t know how to securely manage a certificate authority because they don\u2019t necessarily handle those responsibilities in their day-to-day jobs.<\/li>\n<\/ul>\n\n\n\n
- Understaffing is a huge issue \u2014 data from Keyfactor and the Ponemon Institute\u2019s State of Machine Identity Management Report 2021<\/a> shows that only 45% of companies say they have staff dedicated to managing their PKI.<\/li>\n\n\n\n
- Private PKI (Private CA)<\/strong> \u2014 This refers to PKI that is only used to secure your internal network. The certificates won\u2019t be automatically trusted on all devices \u2014 you\u2019ll 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<\/a>).<\/li>\n<\/ol>\n\n\n\n
- Intermediate CAs:<\/strong> This type of CA serves as one or more links in the certificate chain and is digitally signed\/issued by the root CA. They\u2019re 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.<\/li>\n\n\n\n
- Private key<\/strong> \u2014 This key decrypts data and is kept secret by the owner of the associated certificate.<\/li>\n<\/ol>\n<\/li>\n\n\n\n
- Code signing certificates<\/strong> \u2014These digital certificates help you secure your supply chain for software updates and offer users assurance that your software is legitimate and hasn\u2019t been tampered with. Code signing certificates<\/a> come with one of two validation levels \u2014 standard or extended validation \u2014 and the latter makes Windows Defender SmartScreen warnings disappear because they make your software automatically trusted by Windows operating systems and browsers!<\/li>\n\n\n\n
- SSL\/TLS certificates<\/strong> \u2014 These certificates are what make the secure padlock icons appear in your website visitors\u2019 browsers and the \u201cnot secure\u201d warnings disappear. SSL\/TLS certificates<\/a> come with three validation level options \u2014 domain validation (DV), organization validation (OV), and extended validation (EV).<\/li>\n\n\n\n
- Digital certificates.<\/strong> 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\u2019s issued to (depending on the validation level it\u2019s issued with) but has a finite lifespan. Common digital certificate categories include:\n
- Privately Trusted PKI.<\/strong> If you\u2019re using PKI to secure internal assets or networks, then running a private CA might be the best option. In this scenario, you\u2019ll need to make your own decisions about the PKI architecture \u2014 we\u2019ll go over the basics of what you need to know in this article.<\/li>\n<\/ul>\n\n\n\n