The use of a Public Key Infrastructure (PKI) by an organization demonstrates a dedication to cybersecurity. It enables passwordless authentication, encrypted communication, and it has been listed by organizations such as CISA, NSA, and NIST as a foundational piece of a modern, zero-trust security framework.
In full disclosure, we are a PKI provider. We offer a managed, cloud PKI service that is used by over a thousand organizations across the globe. PKI and digital certificates are complicated, something even very senior security admins we work with don’t completely understand, so we wanted to write an unbiased guide that covers everything we’ve learned throughout the years.
This guide was written with the help of over 10 of our most trusted engineers who have decades of experience, and at no point was generative AI used to help research or write this article. So sit back, and enjoy!
What is a PKI (Public Key Infrastructure)?
At a very high-level, the purpose of a PKI is to allow organizations to use encryption for their various security needs. It allows phishing-resistant authentication to applications or Wi-Fi. It enables your web servers to communicate in encrypted tunnels. It’s even used in your credit cards and car keys. But a PKI, like its name implies, is a complete infrastructure that contains many incredibly complex components. It requires this, because the digital certificates it produces as a replacement to passwords, take up to 300 trillion years to crack with a supercomputer. That’s over 16,000 times longer than the universe is estimated to be in existence! Compare that to most common passwords, that get brute forced in minutes.
The most common way that PKI certificates are used in the real world, is through the use of public-private key cryptography. This is where anyone can use a public key to encrypt a message and send to someone else. This is great, because passwords are easily stolen over the air or internet. When a hacker steals an encrypted message, they can’t do anything about it, even if they knew the public key. Plus, most private keys are locked on to the hardware of devices, making them nearly impossible to steal, unlike passwords where it’s extremely trivial. All in all, PKIs and digital certificates are incredibly important and technologically advanced facets of cybersecurity. If you’d like to learn more, keep reading this article and we’ll break it down piece by piece.
How Does a PKI Work?
What a PKI enables organizations to do, is create numbers that are theoretically impossible for an outsider to guess, but quick and easy for an insider to prove. This is what we call Asymmetric Encryption. The classic way of explaining Asymmetric Encryption is the Alice and Bob diagram.
Source: USNA.edu
Alice wants to send a private encrypted message to Bob. She also doesn’t want anyone else to read it. So she uses Bob’s public cryptographic key, which as you guessed it public, to create a cyphertext that’s encrypted. Because she used Bob’s public key, only his private key can decrypt the message. If Bob wants to send a message back, he will use Alice’s public key just like she used his. Just like that, we have way to pass encrypted data to each other!
Source: Computerphile
The core of how a public key infrastructure is able to achieve strong asymmetric encryption is simply brilliant mathematics. It revolves around taking two huge prime numbers (on the order of 2^512!) and factoring them, but trying to explain the process in just one sentence is almost impossible. Luckily, there’s an awesome channel called Computerphile, and is one of the main ways we train new employees at SecureW2 how a cryptographic keys, and asymmetric encryption works! We recommend watching these two videos if you get a little confused reading this section.
- Public Key Cryptography ← how public key infrastructure works at a high level!
- Diffie Hellman – The Mathematics ← the math behind asymmetric encryption!
What are Digital Certificates?
The purpose of a public key infrastructure pki is to issue and manage digital certificates. But what even is a digital certificate? Is it the same as the public and private keys that Alice and Bob were using? Well, yes they are, but no they aren’t!
A digital certificate should be thought of as a passport. It’s a phishing resistant form of verifying your identity with a trusted third party, and one of the most surefire way organizations can ensure their authentication mechanisms are phishing-resistant. This digital certificate lives on your device, and is presented to systems during authentication. One common way digital certificates are used is to show an Identity Provider like Azure or Okta that you are a particular user using a specific device. The below video shows what it looks like using a digital certificate with Okta.
Is a Digital Certificate the Same as a Private Key or Public Key?
No, a digital certificate is not the same as a public key. However, it does contain your public key. A digital certificate, which can also be referred to as a PKI certificate, should be thought of as a digital passport, or a driver’s license. Your digital passport should contain information about you, right? A PKI certificate contains a customizable amount of information. Common attributes encoded in a PKI certificate are email addresses, first and last names, the groups a user is associated with in the Identity Provider, the serial number of the device, an Azure Device ID, and other bits of identifiable information.
Public keys are also on PKI certificates and are public for all to see. This is necessary, or a third party wouldn’t know how to ensure that the certificate was really you. The private key, however, is not on your PKI certificate. While your device understands the two are linked to each other, the private cryptographic key never leaves the device, should never be seen by anything other than your computer, and is stored securely in a special part of your device, commonly a TPM or Secure Enclave.
What are the components of a Public Key Infrastructure PKI?
The components of a public key infrastructure are sometimes debated, as there have been a lot of recent developments in the field of PKI certificates. In our opinion, the components of a public key infrastructure comprise of everything your organization needs to feel comfortable managing the entire certificate lifecycle. The below components are what we consider to be a modern Public Key Infrastructure.
- Certificate Authority (CA)
- Root Certificate Authority
- Intermediate Certificate Authority
- Certificate Templates
- Certificate Lifecycle Management
- Certificate Policies
- Method of Certificate Revocation
- Certificate Revocation List (CRL)
- Online Certificate Status Protocol (OCSP)
- Hardware designed for cryptographic functions
However, to truly understand all the components of a PKI, and how to configure them properly can take a lifetime. In the following sections, we try out best to summarize each component.
Certificate Authority (CA)
The CA generally handles all aspects of the certificate management for a PKI, but can only do so much on it’s own. A CA issues digital certificates to be used to confirm that the subject imprinted on the certificate is the owner of the public key. In a PKI system, the client generates a public-private key pair. The public key and information to be imprinted on the certificate are sent to the CA. The CA then creates a digital certificate consisting of the user’s public key and certificate attributes. The certificate is signed by the CA with its private key.
Certificate Authorities are all around us. Click on the lock near the URL of your web browsers, and you can see the Certificate Authority that is used to create encrypted web traffic between the web server and your web browsers. Certificates used for Internet Encryption are often referred to as SSL certificates. SSL certificates are an incredibly important part of internet security. Without them, online banking would be pretty dangerous, as anyone could see all the data you were transacting with your bank!
Root Certificate Authority
A Root CA is a trusted CA that is entitled to verify the identity of a person and signs the certificate that is distributed to a user. Your trusted Root Certificate Authority is something that needs to be handled delicately, because if it’s compromised, then all the trust in your PKI fails. It’s for this reason, that these trusted root certificates are not issuing your end user’s digital certificates directly, but instead issuing intermediate CAs that subsequently issue the client certificates. Root CAs, since they are sensitive, are almost always stored in a very secure manner, away from the public internet.
Intermediate Certificate Authority
An Intermediate CA is also a trusted CA and is used as a chain between the root CA and the client certificate that the user enrolls for. Since the root CA has signed and trusts the intermediate CA, certificates that are generated from the intermediate CA are trusted as if they were signed by the root CA. As a best practice, always issue certificates from an intermediate CA.
Certificate Templates
Certificate templates are used to determine how a certificate is structured, and what it will be used for. For Public Key Infrastructures like Active Directory Certificate Services (AD CS), Certificate Templates are enormously important and dictate much of the permissions required for receiving a certificate and what it will be used for. Exploiting a misconfigured certificate template in AD CS is one of the most common compromises.
Below is an example of a Default Certificate Template in the SecureW2 PKI. You can see things like Validity Period, Signature Algorithim, EKU (what the certificate will be used for), and much more!
Certificate Lifecycle Management
A certificate management system is a very important part of a PKI. Lifecycle management encompasses all phases of the certificate lifecycle, which can be broken down into the following phases.
- Certificate Enrollment – An entity submits a request for a certificate to the Certificate Authority (CA). An entity can be a person, a device, or even just a few lines of code.
- Certificate Issuance – The CA needs to validate the identity of the applicant, which is typically done through credentials or by trusting another CA that has already validated the applicant.
- Certificate Validation – Every time the certificate is used to authenticate, the RADIUS server checks with the CA to confirm that the certificate is still valid and hasn’t expired or been revoked.
- Certificate Revocation – Certificates contain an expiration date that’s specified when they are first issued, usually for a duration of several years. When that date is reached, the certificate will automatically be considered invalid for any authentication attempt.
- Certificate Renewal – Instead of automatically being shunted to a CRL, some CA’s have settings that renew certificates upon expiration date, though typically they re-verify identity. At this time, you can choose whether or not to generate a new key pair – effectively making it a totally new certificate.
Effectively managing certificates can be simple if you have a proper automation tool, well secured certificate database, and methods of synchronization between your certificate database and your Identity Providers. A common way organizations automate certificate management is using the Intune CA Partner API. It’s implemented with SecureW2’s PKI, so all devices are scanned every 10 minutes.
Certificate Policies
This enables organizations to create really cool, automated certificate policies. One example is to revoke certificates when Intune says a device is not compliant or issue a certificate that is given lower levels of authorization.
Certificate Policies in general should be aligned closely with existing policies in your Identity Provider or MDM. This is what makes APIs like the Intune CA Partner API so great, because it’s just an extension of all the policies that exist in Intune.
Methods of Certificate Revocation
How you revoke digital certificates is a critical piece of how you manage public key encryption. Large organizations are issuing certificates for thousands of their employees, and it’s a big liability if they are in the hands of users or devices that shouldn’t otherwise have them. Certificate Lifecycle Management and Automation solutions have quickly gained popularity as legacy PKIs often required a lot of manual work to ensure certificates were revoked in a timely fashion.
Certificate Revocation List (CRL)
A CRL is a list of the serial numbers of certificates revoked before their expiration date. Certificate revocation lists are downloaded and cached into a service authenticating certificates, allowing the service to efficiently check for revoked certificates. This is one of the reasons why CRLs are preferred over OCSP which has to check a server for every authentication request.
Base CRL vs Delta CRL
Certificate Revocation Lists are incredibly resilient by design. They are able to be downloaded and cached efficiently because they are broken down into Base and Delta CRLs. A Base CRL contains a list of all the revoked certificates from all-time, and is typically updated weekly. A Delta CRL is usually updated daily and contains only up to a week’s worth of certificates.
Online Certificate Status Protocol (OCSP)
OCSP is a longstanding protocol that is mostly used by web servers. Everytime the authentication process happens. A request is made to the OCSP server to check to see if the certificate requesting authentication is still valid. The OCSP server then looks up the certificate within its list of all it’s certificates and returns a yes or no response.
Hardware Security Module (HSM)
A Hardware Security Module isn’t a mandatory component of a PKI, but it improves the security of the PKI as a whole when implemented. This device protects and manages digital keys and serves as the groundwork for building a secure enterprise PKI infrastructure. The HSM contributes to managing the complete lifecycle of cryptographic keys, which includes creation, rotation, deletion, auditing, and support for API’s to integrate with various applications.
What can a PKI be used for?
A PKI has a multitude of uses, but how your organization designs it depends largely on what your security needs are, which vendor you choose, or if you decide to construct your own. The most common applications of a PKI include Wi-Fi authentication, web application authentication, email security, and VPN. Below we’ll demonstrate how each is tied to the PKI.
Wi-Fi Authentication:
The PKI allows users and systems to verify the legitimacy of certificate-holding entities and securely exchange information between them over the air. The introduction of a PKI enables stronger, certificate-based security, as well as identity services and management tools to maximize network efficiency and security.
Certificate-based Wi-Fi authentication uses the EAP-TLS protocol. The TLS stands for Transport Layer Security, and is generally used as a term to describe any certificate-based authentication. At it’s core, the authentication process is the same as any asymmetric authentication, where the client presents it’s public key, and the authenticator (the RADIUS Server) verifies it with a private key.
Web Application Authentication:
Similar to Wi-Fi authentication, a user connecting to a web application will have their identity confirmed by the web application server. Since the certificate is signed by the trusted CA, they are able to gain access to the application.
VPN Authentication:
Certificates can be used to authenticate users for VPN access. Since VPNs can grant access to critical information, certificates are a preferred method of authentication over passwords. Usually the Root/Intermediate CA is stored on the Firewall and once the user is authenticated, a secure tunnel is created to access the network the user is trying to access.
Email Security:
Encrypting emails with certificates utilizes the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol. Both the receiver and sender are required to have a certificate signed by the CA to establish trust between the users. S/MIME provides the cryptographic security required to guarantee the origin of the message with the digital signature from the certificate, encrypt the message, and authenticate the recipient’s certificate to decrypt the message. If you’d like to learn more about how this protocol protects the integrity of internal communications, learn more here.
What is a Certificate Trust Chain?
This multi-leveled hierarchy of trust is called a certificate chain. You can trace the chain from the client’s certificate all the way back to a single root CA, and every chain ends with a person (or company) from which all the trust is ultimately derived.
In practice, these chains tend to interlink with other chains – often from other CAs. And those CAs often choose to implicitly trust each other, accepting a signed certificate from another CA without validating it themselves. That’s called federation, and while it makes things easier, it means the trust store is only as secure as the weakest link.
More than one CA can sign a certificate, which increases the trust you have that it is accurate because more than one CA has validated it. When more than one CA signs a certificate, it’s called cross-signing. Cross-signing expands trust within your network. When a certificate is signed by two CAs, it allows the certificate to verify trust by more than one CA without the need to distribute a separate certificate for each CA. Cross-signing is still effective when one CAs private key is leaked, as you can issue a revocation for all the public keys for that CA, but the certificates that were cross-signed can still maintain a level of trust with the other CA without the need of reissuing certificates for the CA that was revoked.
What Are Some PKI Algorithms?
AES 256 Certificate:
The AES 256 certificate is an algorithm and the current encryption standard. The previous standard was AES 128. AES 256 keeps track of vulnerabilities and when the encryption has been breached, a higher standard of encryption will be implemented. The higher the standard encryption, the better cryptic the public/private key pair is. An AES 256 certificate is a long length key that causes brute force attacks by would-be credential thieves virtually impossible.
Diffie Hellman:
Diffie Hellman, also known as exponential key exchange, is a method of encryption that uses numbers raised to specific powers that produce decryption keys on the basis of components that are never directly shared, making it overwhelming for potential threats to penetrate. The algorithm creates a mathematically complex encryption that is shared between two parties over a secret communication over a public network so that they can allow an exchange of a private encryption key.
RSA Key Exchange:
RSA, named after its inventors Ron Rivest, Adi Shamir, and Leonard Aldeman, is much like the Diffie Hellman algorithm and factors large integers that are the product of two large prime numbers. RSA key exchange uses public and private keys, while the public key can be shared with everyone, the private key must be kept secret. However, in RSA cryptography either of the public or private key can be used to encrypt a message while the other is used to decrypt.
RSA vs Diffie Hellman:
Although both algorithms exceed the recommended key length for encryption systems (both algorithms sit at 1,024 bit keys while the current standard is 256), the Deffie Hellman algorithm is susceptible to the infamous MITM attack as it does not authenticate either party in the exchange. This is why Deffie Hellman is best used in a combination with another authentication method, generally being digital signatures.
RSA also has its pitfalls, even though RSA can be used for signing digital signatures, even 2,048 bit key lengths have been vulnerable to Man-in-the-browser (MITB) attacks. This attack is much like the MITM attack, however it implements a Trojan Horse to intercept and manipulate calls between the executable (browser) and its security measures or libraries on-the-fly.
DSA:
The DSA, or digital signature algorithm, is used to create digital signatures. DSA was created in 1991 by the National Institute of Standards and Technology and is the standard for government agencies.
The pitfall of the DSA algorithm is that it can only do digital signatures and not public key encryption. However, the advantage lies within the algorithms speed of producing a digital signature.
What is TLS Cipher Suite?
TLS Ciphersuites is a collection of TLS protocols, such as TLS 1.0, 1.2, 1.3, and so on and is the application that supports all the TLS protocols. Before TLS came to be, SSL was the go to protocol. Some wrappers only support certain versions of TLS, Whereas SecureW2 wrapper supports any version of TLS when onboarding a user’s device. However, like most, TLS 1.0 support has been dropped due to growing vulnerabilities.
What is a Microsoft PKI?
Microsoft offers a commonly used PKI called “Active Directory Certificate Services” (ADCS). It was designed to work with the Microsoft environments (AD, NPS, GPO) that historically dominated IT infrastructures.
While some still use AD CS, many organizations are moving away from it due to the limitations that come with being designed for legacy infrastructure. It requires a lot of human resources to deploy and maintain, along with the fact that it requires everything to be on-premise, which can prevent organizations from moving to an all-cloud environment which is where the industry is heading.
Does EAP-TLS use a PKI?
The EAP-TLS authentication method does use a PKI. EAP-TLS is a WPA2-Enterprise network protocol that is used for encrypted, certificate-based authentication. As a user connects or enrolls to the secure network, EAP-TLS authentication confirms the identity of the user and the server in an encrypted EAP tunnel that prevents outside users from intercepting credentials or other information sent over-the-air. They can safely transmit data through the tunnel, resulting in a fast, secure, and successful authentication.
What are examples of a PKI in use?
The physical installation of a PKI to existing infrastructure is a common method of deployment. The setup process involves the setup and configuration of all the PKI components, as well as ongoing maintenance and a requirement to store it in a secure area to protect against a physical breach.
Maintaining strong security around the PKI is of utmost importance. If the public key or Root CA is compromised, every certificate would be at risk and need to be replaced and the organization would be highly susceptible to data theft. The term for responding to such an event is Disaster Recovery, and restoring a local PKI can be an intensive process.
A cloud PKI solution, like the PKI offered by SecureW2, requires no forklift upgrades to integrate directly with existing infrastructure. IT need only connect the PKI to the network and configure the settings and onboarding software to distribute certificates. Since the PKI is externally hosted, the responsibility of maintaining and securing the PKI falls to the vendor.
A cloud PKI also has strong scalability, so as an organization grows, they do not have to consider how to accommodate the new users as you would with a local PKI. The costs over the lifetime of a cloud PKI are significantly lower than the costs of a local PKI because of the lack of traditional costs, such as the installation or on-premise security.
The configuration of a PKI on your network brings stronger security and the tools to simplify and expand the network management scope. Users outfitted with certificates and browsing on the secure network are protected from all manner of over-the-air attacks. The network admins are saved from manually configuring each device for certificates, and they can easily monitor network activity, investigate connection issues, and revoke certificates when they are no longer needed. A PKI provides straightforward solutions to many problems and inefficiencies faced by all organizations with unsecured wireless networks.
SecureW2 offers affordable options for organizations of all shapes and sizes. Click here to inquire about pricing.
