In this article I want to explore, and demystify, the subject of Public Key Infrastructure (PKI) and certificates.
I’ve made a career out of taking on the challenges that nobody else wants to embrace. One of the most common subjects I’ve seen fellow professionals steer away from is typically referred to as “certificates” but what we’re really talking about is Public Key Infrastructure (PKI). Honestly, it’s not as complicated as it seems, but my theory is that it seems hard because the nature of certificates is that they tend to last for long enough that you forget how you got them working/renewed last time, and that scares people away. I’m not going to get into the deep technical details of PKI in this article, I’ll save that for another time. What we’ll explore here is the concepts and high level processes that go into setting up and working with PKI, so that you can understand the important parts of the process and be able to ask the right questions when you need to.
So, let’s dive in and start making you a PKI expert!
What is PKI?
Let’s start with answering the question “What is PKI?”.
We’ll get to the “key” part of PKI in a moment, but let’s start by saying that Public Key Infrastructure (PKI) is a critical component of modern computing to help us ensure the security, integrity, and privacy of data and communications. It is built from a set of technologies and processes that come together as a framework to create and manage digital certificates. These certificates can be used to secure communications, authenticate users, and ensure the integrity of data amongst the many potential uses.
The core concepts to understanding PKI are hierarchy and trust. In short, certificates are issued by an authority, a certificate authority (CA). If you trust the CA, you can trust the certificates it issues. Think of it like a friend recommending a restaurant to you; if you trust your friend, you’re more likely to trust the restaurant they recommend. The CA is your friend, the certificate is the recommendation, and you are the client.
Where it does start to get more complicated in when we start to think about hierarchy. The reality of modern computing is that we need to create abstractions to apply management and security strategies. For example, if PKI is all about trust then the certificate authority is a prime target for attack; so we commonly look to defend our Root CAs by doing things like turning them off, or running them offline. But we still need to do things, like issue new certificates, so we create Intermediate CAs to do that work for us. This creates a hierarchy of trust, where the Root CA is at the top, and Intermediate CAs are below it. Again, think of your friend and the restaurant. Your fiend has told you that you can trust the restaurant, so now when the waiter recommends a dish you’re more likely to trust that too.
A common PKI hierarchy might look like this:
Don’t worry too much about the specifics of the hierarchy just yet, we’ll get to that in a moment. For now, just understand that we have this hierarchy and that we need to trust the hierarchy (in some way, again we’ll get to that in a moment) to trust the certificates and therefore the services using them.
The “key” part of PKI
So, what about the “key” part of PKI?
Well, at it’s heart PKI is an implementation of cryptography (no not “crypto” and cryptocurrencies, although they are related). Cryptography is the science of securing communications and data. In the context of PKI, we’re talking about asymmetric cryptography. Asymmetric cryptography uses a pair of keys, a public key and a private key, to encrypt and decrypt data. The public key can be shared with anyone, while the private key must be kept secret. In this implementation one key can be used to encrypt data, and the other key then must be used to decrypt it. When a server using PKI sends data to you, it will sign that data with its private key. You can then use the server’s public key to verify the signature and ensure the data has not been tampered with. The reverse can then happen too, when you send data to the server you can encrypt it with the server’s public key, and the server can then decrypt it with its private key. Which looks a bit like this:
Spoiler alert: it’s actually more complex than this, but this is a good starting point to understand the basics of PKI.
For now, just know that as we work through understanding PKI there will be private/server keys and public keys in use as we discuss certificates.
So what is a certificate?
Now that we understand what we mean by PKI, and we know that keys exist, let’s take a moment to understand what a certificate is.
A certificate is a digital document that contains information about the entity it represents. This information can include the entity’s name, the entity’s public key, validity period for this certificate, and the certificate’s issuer. The certificate is signed by the issuer, a CA, to ensure that the information contained within the certificate is accurate and has not been tampered with.
So, any server that you connect to securely, like you bank for example, will present you (or more accurately your computer) with a certificate. You and your system must then decide if you trust that certificate. If you do, then you can use the public key contained within the certificate to encrypt data that only the server can decrypt. The server can then use its private key to sign data that you can verify with the public key contained within the certificate. Thus we have a mechanism for ensuring that communication between your computer and the server is secure and that the data has not been tampered with.
Here is the certificate on this website:
Hierarchies
Hierarchies are also referred to as certificate chains, and they are a critical part of PKI in practice.
We’ve touched on the fact that we have these things called Certificate Authorities, normally abbreviated to CAs. The job of a CA is to issue certificates. But, as we’ve also touched on, we need to protect the Root CA as it’s such a prize target for attackers. If you can compromise the Root CA, then you can issue certificates for anything you like. This is a problem because of Trust, which we’ll get to in a moment. For now, let’s just consider what we might do to protect the Root CA. The obvious approach is to turn it off, a system that is turned off, or disconnected from the network, is much harder to attack. But, we still need to issue certificates to servers and services, so let’s create ourselves another CA and sign it’s certificate with the Root CA.
What’s happening here is that we’re now saying, “if you trust our root CA, then you can also now trust this intermediate CA”. Now, of course, this intermediate CA is also a target for attackers, but now, if this one is compromised we can revoke its certificate, and issue a new one from the root CA. As long as the root CA is secure, we can keep doing this and say “if you trust the root CA, then you can trust this new intermediate CA”.
Subordinate CAs, Intermediate CAs, Policy CAs, and Issuing CAs
So, Graham, you keep using these terms like “Subordinate CAs”, “Intermediate CAs”, “Policy CAs”, and “Issuing CAs”, I hear you say, “what do they all mean?”.
Well, let’s break it down.
Root CAs
This is where it all begins. The Root CA is the top of the hierarchy, the most crucial role in the hierarchy. The Root is the anchor of trust for the entire PKI below it. If you trust the Root CA, then you can trust all the certificates issued by the Root CA, and all the certificates issued by the CAs below it. This all makes the Root CA the most critical part of the PKI, and the most likely target for attackers. To combat this, the Root CA is typically turned off, or at least disconnected from the network, and only brought online when it’s time to issue a new certificate to the next tier of subordinate CA(s).
Subordinate CAs
A Subordinate CA is simply a CA that is below another CA in the hierarchy. We can see this is the diagram above, where the Subordinate CA is below the Root CA. That’s it, nothing more, a subordinate CA is just a CA that is below another CA in the hierarchy.
Intermediate CAs
An Intermediate CA is a CA that is below another CA in the hierarchy, but it’s not the last CA in the chain. So it is a subordinate CA, but it’s not the last subordinate CA in the chain. Let’s revisit the diagram from the start of this article:
In this diagram, the Policy CA is an Intermediate CA. It’s subordinate to the Root CA, but it’s not the last CA in the chain. The two Issuing CAs are subordinate CAs to the Policy CA.
Policy CAs
Now let’s get into the practicalities of deploying CAs and building out a PKI. A common pattern for deploying PKI is to separate out the roles of the CAs. The Root CA is the most secure, and the most critical, so we want to protect it as much as possible. The Root CA is typically turned off, or at least disconnected from the network, and only brought online when it’s time to issue a new certificate to the next tier of subordinate CA(s). The next tier of CAs are most commonly referred to as Policy CAs. The Policy CAs are responsible for defining the policy for the PKI, such as the validity period for certificates, the key length, and the algorithms used. The Policy CAs are also responsible for issuing certificates to the next tier of CAs, typically the Issuing CAs.
Issuing CAs
Now, we get to the day to day, core functionality of CAs. The Issuing CAs are responsible for issuing certificates to end entities, such as servers, services, and users. The Issuing CAs are the most commonly used CAs in the PKI. They are also the most likely to be compromised, because they are the most exposed to clients and the network. By having the Policy CAs and a Root CA above the Issuing CAs, we can protect the validity of the chain, the hierarchy, by revoking the certificate of an Issuing CA if it is compromised, and issuing a new certificate from the Policy CA.
Trust
Let’s talk about trust.
Trust is a critical component of PKI. If you don’t trust the CA that issued the certificate, then you can’t trust the certificate presented to you by a given server or service. That being said, we actually don’t need to know about, or trust every CA, and server certificate. The whole idea of PKI is that we can, in theory at least, simply trust a small number of Root CAs and that will then allow us to trust all the CAs and certificates issued below then, in their chain of trust.
Restated simply; if you trust the Root CA, then you can trust any certificate which includes the Root CA at the top of the chain of trust.
Let’s take a deeper look at the certificate on this website:
Here we are looking at the certificate chain for this website. The certificate chain is the chain of certificates that lead back to the Root CA. In this case, the Root CA is DigiCert Global Root CA. DigiCert are actually, in this case, only using a single subordinate CA to issue certificates. So we have a subordinate that is an Issuing CA in this case. The certificate for this website is issued by the GeoTrust Global TLS RSA4096 SHA256 2022 CA1. So our chain looks like this:
Now, depending on your system you may, or may not, have the GeoTrust Global TLS RSA4096 SHA256 2022 CA1 certificate in your trust store. But, as long as you do have the DigiCert Global Root CA certificate in your trust store, then you can trust the certificate for this website.
We can actually see that on my system, right now. Don’t worry so much about the command that I am running, just note that whilst I do have the Digicert Global Root CA certificate in my trust store, I don’t have the GeoTrust Global TLS RSA4096 SHA256 2022 CA1 there.
trust list --filter=ca-anchors | grep -iE 'DigiCert Global Root CA|GeoTrust'
label: DigiCert Global Root CA
label: GeoTrust Global CA
label: GeoTrust Global CA 2
label: GeoTrust Primary Certification Authority
label: GeoTrust Primary Certification Authority - G2
label: GeoTrust Primary Certification Authority - G3
label: GeoTrust Universal CA
label: GeoTrust Universal CA 2
Yet, my browser is happy to show me this website and report the connection as “secure”.
This is the trust hierarchy in action. My system trusts the root CA, and so therefore it can trust the certificate for this website, even though it doesn’t have the intermediate CA certificate in its trust store.
Importing certificate chains
Now, if you’ve ever worked with PKI or signed your own web server then you’re probably out there saying “but my certificate issuer gave me a chain file and the instructions were clear that I had to install it”, or perhaps you run your own PKI and always make sure that you import the full chain of CAs. Whilst yes, just trusting the root CA should be enough, it can require additional processing to go out and fetch and verify each certificate in the chain. So, it’s often easier, and better practice, where possible, to import the full chain of CA certificates into your trust store. Service verification and page load will be faster, and you’ll have more confidence that the certificate is valid.
Another reason is that some systems, like browsers, will only trust certificates that are signed by a CA that they directly trust. So, if you’re running a web server, and you want to make sure that all browsers trust your certificate, then you’ll need to make sure that you import the full chain of CA certificates into your trust store.
Finally there is the issue of revocation. If you have the full chain of CA certificates in your trust store, then you can be sure that you can trust the revocation status of the certificate. If you only have the root CA certificate in your trust store, then you may not be able to trust the revocation status of the certificate, and may not have sufficient information to be able to query the revocation status of the certificate.
Trust errors for self-signed certificates
We’ve not talked about self-signed certificates yet, but let’s touch on them briefly here.
It is possible to generate your own certificate without a CA involved. Infact, many services do this as a default to get their system up and running, and then prompt you to install a signed certificate later, as part of the setup.
When you connect to a service that is using a self-signed certificate, your system will typically report a trust error. This is because your system doesn’t trust the certificate. This is because it’s not signed by a any CA that it is aware of. You can still connect to the service, but you’ll need to manually approve the connection acknowledging this unrecognised certificate, or you can manually import the certificate into the trust store. But, you should be aware that the certificate is not signed by a CA that your system trusts, and so you should be cautious about trusting the certificate.
Revocation
The last thing that we will discuss today is the concept of revocation, seeing as I’ve mentioned it a few times already.
Revocation is the process of invalidating a certificate before it’s expiry date. This can happen for a number of reasons, such as the issuing CA, or the certificate itself being compromised, the certificate being issued in error, or the certificate being revoked by the CA for some other reason. When a certificate is revoked, the CA will issue a new certificate to replace the revoked certificate. The CA will also publish the revocation status of the certificate in a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP) response. These mechanisms allow clients to check the revocation status of a certificate before trusting it.
If your client identifies that a certificate has been revoked, then it should not trust the certificate (or the CA if the CA itself is revoked). In this case it can report a trust error, or simply refuse to connect to the service.
Conclusion
So, there you have it, a high level introduction to Public Key Infrastructure (PKI) and certificates. We’ve covered the basics of PKI, the hierarchy of CAs, trust, and revocation. We’ve also touched on the importance of trust, and the implications of not trusting a certificate. I hope that this article has helped to demystify PKI and certificates for you, and that you now feel more confident in understanding the concepts and processes involved in PKI.
I’ll be writing more about PKI in the future, so if you have any questions or topics that you’d like me to cover, then please let me know.
If this article helped inspire you please consider sharing this article with your friends and colleagues, or let me know via LinkedIn or X / Twitter. If you have any ideas for further content you might like to see please let me know too.
