Public Key Infrastructure (PKI) is the unsung hero of cybersecurity.
For most people, the term cybersecurity will immediately evoke images of holograms, retina scanners and multi-touch devices. A tech ensemble that wouldn’t look out of place in Q’s workshop, the Minority Report, or even the Pentagon. And to some degree that’s a somewhat valid view. There are many different types of cybersecurity, however, most would be surprised to learn that one of the most effective forms of cybersecurity isn’t remedatory, but is concerned with how digital entities establish secure connections in the first-place. A solution that is baked into a system or service from the get-go.
And this is where PKI comes in.
PKI doesn’t require teams of people shrewdly overlooking various dashboards with sonar-like devices dotted intermittently in between. PKI is about creating a technical ecosystem that makes it impossible for the bad guys to even get in.
It’s encryption at scale.
Of course, there will always be room for machine learning or prescriptive analytics in the world of cybersecurity. There is no one-size-fits-all approach. Organisations need to be equipped and ready when clandestine attacks do make their way into the system. However, PKI is a proactive attempt to stop malevolent connections from happening in the first place. How? Let us explain…
What is Public Key Infrastructure (PKI)?
First, we need to understand that PKI isn’t a single product or service.
You can’t head on over to your local supermarket, browse the encryption aisle and chuck four PKIs into your shopping basket. A PKI is a network of activity that comes together to ensure messages between two parties are encrypted and tamper resistant. It’s essentially a validation exercise that digitally proves you are who you say you are so cybercriminals can’t capture sensitive details by masquerading as somebody else.
One of the most commonly understood examples was the move from HTTP to HTTPS.
Back in the day most websites were served over unencrypted HTTP, which was all well and good until cybercriminals learned how to mimic and hijack websites in place of legitimate businesses. The issue? There was no verification step that detailed to the user that they were dealing with their intended party.
Hence the arrival of HTTPS.
Now, when you navigate to a website, there should be a little lock symbol next to the website domain. If you click on the lock, there will be a “connection is secure” option listed in the dropdown. This will look similar to the below 👇
Next, if you click “certificate is valid” this will open a new window that shows the details of the digital certificate. This proves that the website is served by whoever owns the domain “example.org”. But how one might go about obtaining such a certificate, well, that’s all part of the process that makes up a PKI.
A PKI is a mixture of cryptography, public & private keys, certificate authorities (CAs), revocation lists, and more. Of which, our parent company, Venafi, has pulled together an excellent 101 style video that explains how these components all come together to create a PKI. However, for those that prefer the written word, we’ll now take a closer look at each of these components and explain how - through encryption - digital entities can obtain the digital certificates they need to establish a secure connection.
It Starts With Cryptography
The whole process starts with a pair of keys. One public and the other private. This is otherwise known as public key cryptography or asymmetric cryptography.
These two keys allow IT systems to establish secure connections or send highly confidential information by way of encryption. And whilst each key will each contain a unique set of digits, a mathematical relationship will exist between the two. Some super smart algorithms essentially tie the two keys together, allowing the private key to “sign” data which can later be verified by anyone using the corresponding public key.
And how might this play out IRL?
Let’s stick with our website analogy and see what happens when a user visits a website. Bear in mind that modern TLS tends to work a little differently to what is described below - for various reasons we won’t get into during an introductory blog - but the principles remain largely the same.
First, the client (a user’s device) will send a message to the web server requesting to start a new encrypted session. Happy to oblige, the web server will then send across its public key. The client will send back a “pre-master key” - a key encrypted using the server’s public key - that can only be decrypted using the web server’s private key. Once decrypted, both the client and server can use the pre-master key to create a shared secret key (or a “shared secret” as it’s colloquially known) which is used to encrypt all traffic between the client and the server. So, from this point, an encrypted session has been established between the client and the web server. Wahoo!
“Erm, but can’t someone just present their own public key whilst pretending to be the web server?”
Good spot. Whilst asymmetric cryptography provides a highly sophisticated means to encrypt and decrypt messages, the whole process falls down if we can’t verify who owns the public key. But fear not, for the PKI is still incomplete and we need to introduce you to the wonderful world of digital certificates to continue our journey…
Digital Certificates and CAs
As mentioned at the start of this blog, a PKI is a network of activity rather than a single entity or service. And whilst we’ve unearthed some nifty cryptography to get things started, we need to verify the public key owners to really make things tick.
And on that note I’d like to introduce you to Certificate Authorities (CAs).
CAs like Let’s Encrypt, Comodo, and Digicert were all established to verify that digital identities are who they say they are. So, if a digital identity wants to verify public key ownership they’ll need to register this with their preferred CA - which BTW, can be a manual or automated process. Next, once everything checks out and the process is completed, a digital certificate will be issued by the CA.
For those on the hunt for the world’s most boring metaphor, we can liken digital certificates to a driving license, whilst the CAs are the DVLA (or the DMV for our American friends).
If we revisit the screenshots of our website above, visitors can see that there is a certificate in place which validates the ownership of “www.example.org”. Meaning the certificate owner will also hold the private key for this domain.
If you want to go full circle, you can actually view a website’s public key very easily. The screengrab below shows you where you need to head. However, if you’re reading this from a distant future, please note that the key may have since been updated.
It’s probably worth noting at this point that there are such things as public and private CAs. Generally speaking, private ones are used for internal validation and the other public facing workloads, but we’ll save that topic for another day!
What if My Digital Certificate Becomes Compromised?
Good question!
When digital certificates become compromised there are fallbacks in place to restore order when disaster does strike, in the form of CRLs and OCSP, both of which implement certificate revocation. These are essentially “naughty lists” that identify which private keys can no longer be trusted. On the public internet both CRLs and OCSP are rarely used. In practice the big browsers are the ones who do control the naughty list, if any revocation happens at all.
CRLs and OCSP can be used internally with private PKI with some success, but the main counter to compromised private keys today is short-lived certificates; a stolen key isn’t much use if its certificate has already expired!
Managing Certificates in the Cloud: An Introduction to cert-manager
As cloud native has become the de facto standard for net-new applications, technologies like containers and Kubernetes have rapidly increased the number of machine identities (e.g. pods) that would exist within any given application or service. Hence the rapid rise of Machine Identity Management - a new software category that is currently trending in security circles.
Where a monolithic architecture would have a fairly stable, rigid number of machines, the beauty of the cloud means we can now scale up and scale down to keep in line with demand, whilst clusters and microservices means digital certificates have become increasingly ephemeral in their nature. All this complexity muddled together means it has become far more difficult to issue and manage digital certificates within cloud-native environments.
These demands led to the creation of cert-manager - a powerful, general-purpose certificate management controller for Kubernetes.
Since becoming available as an open source project, cert-manager has become hugely popular due to its ability to easily automate TLS certificates for Kubernetes and OpenShift workloads. cert-manager can obtain certificates from a variety of Issuers, both public and private, and ensure the certificates are valid and up-to-date by auto renewing certificates at a pre-specified time.
And when 94% of organisations have encountered a security incident related to a Kubernetes workload misconfiguration, cert-manager can help keep your finger on the pulse and avoid certificate-based application outages altogether. All yours for the princely sum of nought pounds and nought pennies.
Ensuring enterprises have visibility of how their PKI is used by certificates across all Kubernetes clusters can be challenging, especially when clusters are being spun up regularly and infrastructure keeps expanding. In this cloud native world of constant change these companies need to know from which CA each certificate has originated. Jetstack Secure is built on top of cert-manager and is purposefully developed to provide visibility of certificates and the CAs that are issuing them.
If you have your own cluster and want to install cert-manager for yourself then we have a great tutorial available from the Jetstack Academy. You can then build visibility of each certificate running inside your cluster by using Jetstack Secure for free.