The use of a Public Key Infrastructure (PKI) by an organization demonstrates a dedication to the security of the network and the effectiveness of public key encryption and certificate-based networks.
The purpose of a PKI is to manage the public keys used by the network for public key encryption, identity management, certificate distribution, certificate revocation, and certificate management. Once enabled, users who enroll for a certificate are identified for later authentication or certificate revocation.
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.
Table of Contents
- What are the components of a PKI?
- What can a PKI be used for?
- Does SSL Inspection use a PKI?
- Does EAP-TLS use a PKI
- What are examples of a PKI in use?
What are the components of a PKI?
The components of a PKI include:
- public key
- private key
- Certificate Authority
- Certificate Store
- Certificate Revocation List
- Hardware Security Module
A public key system relies on asymmetric cryptography, which consists of a public and private key pair. The Certificate Authority (CA) certifies the ownership of the key pairs and completes the PKI setup.
A Public Key is a cryptographic key that can be distributed to the public and does not require secure storage. Messages encrypted by the public key can only be decrypted by the corresponding private key.
Private Keys are used by the recipient to decrypt a message that is encrypted using a public key. Since the message is encrypted using a given public key, it can only be decrypted by the matching private key. This establishes the ownership of the private and public key, ensuring the message is only read by the approved parties.
Certificate Authority (CA)
A CA issues 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. Once the certificate is distributed to the user, they can present the signed certificate and the receiver can trust that it belongs to the client because of the matching public-private key pair.
Root Certificate Authority
A Root CA is a trusted CA that is entitled to verify the identity of a person and signs the root certificate that is distributed to a user. The certificate is considered valid because it has been verified and signed by a trusted root CA.
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. SecureW2’s PKI always uses the intermediate CA to generate client certificates for Wi-Fi authentication, as it’s a best practice. SecureW2’s intermediate CA can never be compromised, since a hardware level of encryption is used for the private key of intermediate CAs.
Certificate Revocation List (CRL)
A CRL is a list of certificates that have been revoked by the CA that issued them before they were set to expire. This is a helpful security feature if a device is stolen that contains a certificate. A RADIUS server only rejects a connection request from a device if the device’s certificate serial number is contained in the CRL. The Certificate Authority is the one that maintains this list, and the RADIUS server periodically downloads this list by sending a query to the CA. There are two types of CRLs: A Delta CRL and a Base CRL.
Base CRL vs Delta CRL
A Base CRL is a large file containing all revoked certificates. This file is published and updated at infrequent intervals. A Delta CRL is a small file containing the certificates that have been revoked since the last base CRL was published. Typically the Base CRL is updated on a weekly basis, and the Delta CRL is updated on a daily basis. Although, some security conscious organizations prefer a more frequent update, which is why you can configure an update every 15 minutes if necessary. If you revoke a certificate in SecureW2, its serial number will first be added to the Delta CRL before being moved to the Base CRL. Then, when the base CRL is updated, the list of revoked certificates listed in the Delta CRL are appended to the Base CRL.
A Certificate Store is used to store certificates and can potentially contain certificates from multiple CAs. For example, different Windows certificates are stored in the certificate store and can be viewed using MMC snap-in, while in macOS, certificates are stored in the keychain.
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.
The lifecycle of a certificate can be broken into a handful of distinct steps.
- 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 CA automatically adds that certificate to the Certificate Revocation List (CRL), a sort of blacklist that instructs the RADIUS not to authenticate those certificates.
- 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.
A trust store is a list of root certificates (sometimes called trust anchors) that comes pre-installed on a device. It’s composed of more than a hundred of the largest and most trusted CAs such as Digicert, Apple, Microsoft, Symantec, Mozilla, Lets Encrypt, and more.
It serves a couple of very important purposes. First, they sign (validate) the identity of the device for other certificate authorities. The root CAs know the public key of the device and can confirm to any third parties.
Secondly, they “inoculate” the device with trusted certificate authorities. Without pre-installed certificates, the device would have to accept a certificate that wasn’t initially verifiable and just “take their word for it”, and that would be a potential vector for malicious actors to inject a false certificate.
Certificate authorities rarely sign certificates using the root CA directly. Instead they put one or more levels of separation between themselves and the client by creating intermediate certificate authorities. Intermediate CAs are functionally identical, but they have less “authority” because they are responsible for signing fewer certificates. Theoretically, they are just as trustworthy, but in the case that they are compromised, it limits the damage that can be caused.
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 in 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 themself. 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.
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.
Users with a certificate signed by the trusted CA can connect to the secure SSID and be authenticated by the RADIUS server using EAP-TLS. EAP-TLS authentication encrypts data sent through it and protects from over-the-air attacks. The certificate is sent and the RADIUS confirms their identity, establishing trust that grants secure network access.
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.
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.
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.
Does SSL Inspection use a PKI?
An SSL certificate is used to ensure that there is an encrypted connection for online communications with a secured website. SSL certificates are installed in the certificate store of the PKI and decrypt HTTPS traffic to maintain network visibility for administrators.
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.