Table of Contents<\/h4>\nPKI Explained \n<\/a>
\nHow Does PKI Work?\n<\/a>
\nThe Difference Between PKI and SSL\/TLS\n<\/a>
\nWhy Is PKI Important in Cybersecurity?\n<\/a>
\nWhat Is PKI Used For?\n<\/a>
\nHow Does PKI Work?\n<\/a>
\nTypes of PKI Solutions\n<\/a>
\nWhat Are the Main PKI Security Risks and Limitations?\n<\/a>
\nFAQ<\/a>
<\/div>\n\n\n\n\n\nPKI Explained<\/h2>\n\n\n\n
PKI is a framework for issuing, managing, and maintaining digital certificates that link public keys to an identity.<\/strong> This key is a piece of cryptographic code used to secure data. It\u2019s shared openly, unlike its matching private key, which stays secret.\u00a0<\/p>\n\n\n\nThe identity linked to a public key is often referred to as the certificate subject. Depending on the PKI, this may be a person, website, device, service, organization, or application.<\/p>\n\n\n\n
A public key can perform useful cryptographic operations without PKI, but nothing ties it to a specific owner. PKI provides that missing link, giving other systems a basis to trust the key and the identity associated with it.<\/p><\/div>\n\n\n\n
What Are Public and Private Keys?<\/h3>\n\n\n\n
PKI relies on asymmetric cryptography, which uses a pair of mathematically related keys.<\/strong> Users share <\/strong>the public key, while its matching private key must remain under the owner\u2019s control.<\/p>\n\n\n\nThe two keys perform complementary cryptographic operations. Their exact role depends on the algorithm and protocol in use:<\/p>\n\n\n\n
\n- Private keys:<\/strong> Can create digital signatures and prove control of a cryptographic identity. Some cryptographic systems also use them for private operations involved in encryption or key establishment.<\/li>\n\n\n\n
- Public keys:<\/strong> Can verify digital signatures. They can also take part in encryption or key-establishment processes without exposing the corresponding private key.<\/li>\n<\/ul>\n\n\n\n
This is why saying \u201cthe public key encrypts and the private key decrypts\u201d is too simplistic. Some public-key systems work that way for certain operations, while others use the key pair in other ways.<\/p>\n\n\n\n
The mathematics can confirm whether someone controls a key pair\u2019s private key, but the key itself doesn\u2019t identify that person or system. PKI addresses that identity gap.<\/p>\n\n\n\n
What Is a PKI Certificate?<\/h3>\n\n\n\n![\"Diagram](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2026\/08\/whats-inside-a-pki-certificate-1-1016x1024.png\")
<\/figure>\n<\/div>\n\n\nA PKI certificate is a digitally signed credential that connects a public key to an identity. It\u2019s also called a digital certificate or public key certificate.\u00a0<\/p>\n\n\n\n
Many PKI systems use the X.509 standard, which is widely used for web services and enterprise systems.1<\/sup> A certificate usually includes details such as:<\/p>\n\n\n\n\n- Subject:<\/strong> The identity the certificate represents.<\/li>\n\n\n\n
- Public key:<\/strong> The subject\u2019s public key.<\/li>\n\n\n\n
- Issuer:<\/strong> The certificate authority that issued the certificate.<\/li>\n\n\n\n
- Serial number:<\/strong> A unique identifier assigned by the issuer.<\/li>\n\n\n\n
- Validity period:<\/strong> The dates between which the certificate is valid.<\/li>\n\n\n\n
- Key usage:<\/strong> Rules that specify which cryptographic purposes the certificate can support.<\/li>\n\n\n\n
- Subject names:<\/strong> Additional identities covered by the certificate, such as website domain names.<\/li>\n\n\n\n
- Digital signature:<\/strong> A signature created by the issuer to protect the certificate\u2019s contents and identify who issued it.<\/li>\n<\/ul>\n\n\n\n
The subject\u2019s private key isn\u2019t stored in the certificate. It stays separate and should remain protected by the certificate holder. Anyone who receives the certificate can access the public key it contains without gaining access to the private key.<\/p>\n\n\n\n
Presenting a certificate doesn\u2019t, by itself, prove that the holder still controls the corresponding private key. That proof occurs when the holder uses the private key in a way that verifies it pairs with the certificate\u2019s public key.<\/p>\n\n\n\n
What Are the Main Components of PKI?<\/h3>\n\n\n\n
A PKI needs more than certificates and key pairs. Several roles and systems establish the trust relationships that make those certificates meaningful:<\/p>\n\n\n\n
\n- Certificate authority (CA):<\/strong> Signs and issues digital certificates according to the PKI\u2019s rules. Its digital signature links the certificate to its issuer and makes any later changes detectable.<\/li>\n\n\n\n
- Root certificate authority:<\/strong> Sits at the top of the certificate hierarchy and acts as its trust anchor. Its private key needs strong protection, so organizations may keep root CA systems offline when they aren\u2019t needed.<\/li>\n\n\n\n
- Intermediate and issuing certificate authorities:<\/strong> An intermediate CA receives signing authority from a root or another intermediate CA. An issuing CA signs certificates for end entities, which limits how often the root CA needs to use its private key.<\/li>\n\n\n\n
- Registration authority (RA):<\/strong> Checks identities or approves certificate requests on behalf of a CA. It\u2019s an optional PKI role and normally doesn\u2019t sign the final certificate itself.<\/li>\n\n\n\n
- Trust store:<\/strong> Contains the root certificates that a browser, operating system, application, or organization accepts as trusted. Trust stores can differ between systems, so the same root isn\u2019t recognized everywhere.<\/li>\n\n\n\n
- Certificate policies:<\/strong> Set the rules for how to check identities, which certificates to issue, how to protect keys, and what to use those certificates for.<\/li>\n<\/ul>\n\n\n\n
How Does PKI Work?<\/h2>\n\n\n\n
PKI works in two main stages. Certificate issuance comes first, followed by certificate validation. A website certificate provides a familiar example of both.<\/p>\n\n\n\n
How Is a Certificate Issued?<\/h3>\n\n\n\n
Certificate issuance starts with the system or organization that needs the certificate. The exact checks vary by certificate type, but the basic process follows this pattern:<\/p>\n\n\n\n
\n- The requester generates a key pair:<\/strong> The requester creates a public key and its matching private key. The private key stays on the requester\u2019s system or in protected hardware and isn\u2019t sent to the CA.<\/li>\n\n\n\n
- The requester creates a certificate signing request (CSR):<\/strong> The CSR packages the public key and required identity details (e.g., domain names for a website). It\u2019s signed with the requester\u2019s private key to prove ownership of the key pair.<\/li>\n\n\n\n
- The CA validates the request:<\/strong> The required checks depend on the certificate type. For a website certificate, this can include confirming control of the requested domain, while certificates for people or managed devices can require different evidence.<\/li>\n\n\n\n
- The CA signs the certificate:<\/strong> After approving the request, the CA creates the certificate and signs it with its own private key. This confirms the CA approved the certificate under its rules, rather than guaranteeing every possible claim about the subject.<\/li>\n\n\n\n
- The requestor installs the certificate:<\/strong> The requester places the certificate on the server, application, device, or account it will use. The matching private key must remain available to that system so it can prove control of the identity represented by the certificate.<\/li>\n<\/ol>\n\n\n\n
How Do Systems Validate a Certificate?<\/h3>\n\n\n\n![\"The](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2026\/08\/Why-the-Same-Certificate-May-Be-Trusted-on-One-System-but-Not-Another1-1-1021x1024.png\")
<\/figure>\n<\/div>\n\n\nWhen a browser connects to a Hypertext Transfer Protocol Secure (HTTPS) website, the site sends its certificate as part of the connection setup. The browser then checks whether that certificate is valid for the website and whether it leads back to a CA the browser already trusts. The main checks include:<\/p>\n\n\n\n
\n- Identity:<\/strong> The certificate has to apply to the requestor. For a website, the browser checks that the domain name appears in the certificate.<\/li>\n\n\n\n
- Validity period:<\/strong> The current date has to fall within the certificate\u2019s permitted start and expiration dates. The browser can reject a certificate that isn\u2019t valid yet or has already expired.\u00a0<\/li>\n\n\n\n
- Permitted use:<\/strong> The browser must approve the certificate for the operation the system wants to perform. A certificate issued for one cryptographic purpose may not be valid for another.<\/li>\n\n\n\n
- Issuer signature:<\/strong> The system verifies the digital signature made by the certificate\u2019s issuer. A valid signature shows that no one\u2019s altered the certificate since the issuer signed it.<\/li>\n\n\n\n
- Chain of trust:<\/strong> The system follows the chain from the end-entity certificate through one or more intermediate CAs and ends up at a root certificate already accepted in its trust store. The system trusts the root because a trusted party added it to its trust store, not because it\u2019s self-signed.<\/li>\n\n\n\n
- Revocation status:<\/strong> Where certificate-status checking applies, the system may also check whether the CA revoked the certificate before its expiration date.<\/li>\n<\/ul>\n\n\n\n
If the required checks succeed, the system can accept the certificate for that purpose. If validation fails, the application may refuse the connection or show a certificate warning such as \u201cYour connection is not private<\/a>.\u201d<\/p>\n\n\n\nThe Difference Between PKI and SSL\/TLS<\/h2>\n\n\n\n
Transport Layer Security (TLS) keeps your connection private between you and the other party, but it doesn\u2019t verify the other party\u2019s identity. PKI handles that by confirming you\u2019re actually talking to the right server. Secure Sockets Layer (SSL), TLS\u2019s predecessor, is obsolete.<\/p>\n\n\n\n
After the client authenticates the server, TLS derives shared session keys and uses symmetric encryption to protect application data. The certificate authenticates the server, but it doesn\u2019t encrypt the browsing session itself.<\/p>\n\n\n\n
Standard HTTPS<\/a> authenticates the server to the client. TLS can also require a client certificate, but this is optional and more common in controlled environments where a service needs to authenticate connecting users or devices.<\/p>\n\n\n\nWhy Is PKI Important in Cybersecurity?<\/h2>\n\n\n\n
PKI gives systems a reliable basis for recognizing digital identities. This means several security functions can work from a shared trust model instead of establishing trust independently.<\/p>\n\n\n\n
\n- Trusted authentication:<\/strong> Certificates can authenticate users, servers, devices, applications, or workloads. Authentication establishes who or what is connecting, while\u00a0 authorization rules determine what it can access.<\/li>\n\n\n\n
- Data integrity and digital signatures:<\/strong> You can check signed data for changes made after signing, while the certificate identifies the subject associated with the signing key.<\/li>\n\n\n\n
- Certificate-based access decisions:<\/strong> Services can use an authenticated certificate identity when deciding whether to accept a connection. Access permissions are still controlled by the receiving system.<\/li>\n\n\n\n
- Scalable machine identity:<\/strong> Large environments can give each non-human system its own certificate-based identity instead of reusing one shared credential across many systems.<\/li>\n<\/ul>\n\n\n\n
What Is PKI Used For?<\/h2>\n\n\n\n![\"Different](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2026\/08\/Who-Does-the-Certificate-Authenticate-1-856x1024.png\")
<\/figure>\n<\/div>\n\n\nBeyond the web example above, PKI also appears in:<\/p>\n\n\n\n
\n- Enterprise Wi-Fi:<\/strong> Wi-Fi Protected Access (WPA)-Enterprise<\/a> networks can use certificates to authenticate approved users or verify that the access point isn\u2019t a rogue network, rather than relying only on a shared Wi-Fi password.<\/li>\n\n\n\n
- Secure email:<\/strong> Systems such as Secure\/Multipurpose Internet Mail Extensions (S\/MIME) use certificates to support message signing and encrypt messages for specific recipients.<\/li>\n\n\n\n
- Code signing:<\/strong> Software publishers use certificates to associate a signing key with their identity, helping users verify who signed the software.<\/li>\n\n\n\n
- Document signing:<\/strong> Certificates can associate a digital signature with an identified signer and help reveal changes made to the document after signing.<\/li>\n\n\n\n
- Device authentication:<\/strong> Managed hardware and Internet of Things (IoT) devices can receive individual certificate-based identities instead of sharing one credential.<\/li>\n\n\n\n
- Service-to-service communication:<\/strong> Applications and workloads can use certificates to identify themselves when connecting to other internal services.<\/li>\n\n\n\n
- Smart cards and security tokens:<\/strong> These devices can store private keys and the certificates associated with them for certificate-based authentication.<\/li>\n<\/ul>\n\n\n\n
How Do VPNs Use PKI?<\/h3>\n\n\n\n
VPN protocols such as Internet Key Exchange version 2\/Internet Protocol Security (IKEv2\/IPsec) can use X.509 certificates to authenticate VPN peers.<\/strong> In a site-to-site VPN<\/a>, this can mean authenticating the gateways at each end of the connection. Remote-access deployments can also use certificates to authenticate managed devices or users.\u00a0<\/p>\n\n\n\nOpenVPN can also use certificates through TLS to authenticate VPN endpoints. An organization might issue individual client certificates to employees or devices, while the VPN server presents its own certificate during connection setup.<\/p>\n\n\n\n
Certificate-based PKI isn\u2019t universal across VPN protocols. WireGuard, for example, identifies peers by their public keys rather than using X.509 certificates or a CA hierarchy.<\/p>\n\n\n\n
How Does PKI Certificate Management Work?<\/h2>\n\n\n\n
PKI certificate management covers the ongoing work needed to keep certificates organized and usable after they\u2019re issued. It often follows four stages:<\/p>\n\n\n\n
\n- Discover and inventory certificates:<\/strong> Keep a record of each certificate\u2019s location, owner, purpose, issuer, expiration date, and associated system so every credential has a known owner and role.<\/li>\n\n\n\n
- Deploy, renew, and rotate certificates:<\/strong> Install certificates where they\u2019re needed and replace them before they expire. Renewal replaces the certificate, while key rotation creates a new key pair. Automation can help when certificate volumes become difficult to track manually.<\/li>\n\n\n\n
- Revoke certificates and publish their status:<\/strong> Revoke certificates after key compromise. A certificate revocation list (CRL) publishes revoked certificates, while the Online Certificate Status Protocol (OCSP) checks one certificate\u2019s status. Revocation stops trust in the certificate, not use of the private key.<\/li>\n\n\n\n
- Monitor and audit the PKI:<\/strong> Track upcoming expirations, unauthorized certificates, policy violations, revocation status, and CA activity. Audit logs record important actions such as issuance, revocation, configuration changes, and administrative access.<\/li>\n<\/ol>\n\n\n\n
Types of PKI Solutions<\/h2>\n\n\n\n
PKI classifications include trust (public vs. private), operation (managed vs. self-managed), and hosting (cloud vs. on-premise). These dimensions are independent, so a private PKI can still be cloud-hosted or fully self-managed.<\/p>\n\n\n\n
Public PKI vs. Private PKI<\/h3>\n\n\n\n
Public PKI uses CAs whose root certificates are already recognized by common browsers or operating systems.<\/strong> This makes it suitable for internet-facing services that need to work on users\u2019 devices without requiring custom certificate installation.<\/p>\n\n\n\nCAs that participate in public trust programs must follow the requirements set by the relevant browser or operating system vendor. \u201cPublic\u201d describes who can recognize the certificates by default. It doesn\u2019t mean the CA infrastructure is accessible.<\/p>\n\n\n\n
Private PKI creates a trust system for a controlled environment.<\/strong> The organization distributes its own root certificate to the devices or applications that should recognize certificates issued under that PKI.<\/p>\n\n\n\nSystems configured to recognize the organization\u2019s root trust private PKI certificates. External browsers and unmanaged devices won\u2019t trust them by default.<\/p>\n\n\n\n
Managed, Cloud, and Self-Hosted PKI<\/h3>\n\n\n\n
How you deploy PKI depends on your resources, expertise, and how much control you need over the infrastructure. These are your main options:<\/p>\n\n\n\n
PKI Explained<\/h2>\n\n\n\n
PKI is a framework for issuing, managing, and maintaining digital certificates that link public keys to an identity.<\/strong> This key is a piece of cryptographic code used to secure data. It\u2019s shared openly, unlike its matching private key, which stays secret.\u00a0<\/p>\n\n\n\n The identity linked to a public key is often referred to as the certificate subject. Depending on the PKI, this may be a person, website, device, service, organization, or application.<\/p>\n\n\n\n A public key can perform useful cryptographic operations without PKI, but nothing ties it to a specific owner. PKI provides that missing link, giving other systems a basis to trust the key and the identity associated with it.<\/p><\/div>\n\n\n\n PKI relies on asymmetric cryptography, which uses a pair of mathematically related keys.<\/strong> Users share <\/strong>the public key, while its matching private key must remain under the owner\u2019s control.<\/p>\n\n\n\n The two keys perform complementary cryptographic operations. Their exact role depends on the algorithm and protocol in use:<\/p>\n\n\n\n This is why saying \u201cthe public key encrypts and the private key decrypts\u201d is too simplistic. Some public-key systems work that way for certain operations, while others use the key pair in other ways.<\/p>\n\n\n\n The mathematics can confirm whether someone controls a key pair\u2019s private key, but the key itself doesn\u2019t identify that person or system. PKI addresses that identity gap.<\/p>\n\n\n\n A PKI certificate is a digitally signed credential that connects a public key to an identity. It\u2019s also called a digital certificate or public key certificate.\u00a0<\/p>\n\n\n\n Many PKI systems use the X.509 standard, which is widely used for web services and enterprise systems.1<\/sup> A certificate usually includes details such as:<\/p>\n\n\n\n The subject\u2019s private key isn\u2019t stored in the certificate. It stays separate and should remain protected by the certificate holder. Anyone who receives the certificate can access the public key it contains without gaining access to the private key.<\/p>\n\n\n\n Presenting a certificate doesn\u2019t, by itself, prove that the holder still controls the corresponding private key. That proof occurs when the holder uses the private key in a way that verifies it pairs with the certificate\u2019s public key.<\/p>\n\n\n\n A PKI needs more than certificates and key pairs. Several roles and systems establish the trust relationships that make those certificates meaningful:<\/p>\n\n\n\n PKI works in two main stages. Certificate issuance comes first, followed by certificate validation. A website certificate provides a familiar example of both.<\/p>\n\n\n\n Certificate issuance starts with the system or organization that needs the certificate. The exact checks vary by certificate type, but the basic process follows this pattern:<\/p>\n\n\n\n When a browser connects to a Hypertext Transfer Protocol Secure (HTTPS) website, the site sends its certificate as part of the connection setup. The browser then checks whether that certificate is valid for the website and whether it leads back to a CA the browser already trusts. The main checks include:<\/p>\n\n\n\n If the required checks succeed, the system can accept the certificate for that purpose. If validation fails, the application may refuse the connection or show a certificate warning such as \u201cYour connection is not private<\/a>.\u201d<\/p>\n\n\n\n Transport Layer Security (TLS) keeps your connection private between you and the other party, but it doesn\u2019t verify the other party\u2019s identity. PKI handles that by confirming you\u2019re actually talking to the right server. Secure Sockets Layer (SSL), TLS\u2019s predecessor, is obsolete.<\/p>\n\n\n\n After the client authenticates the server, TLS derives shared session keys and uses symmetric encryption to protect application data. The certificate authenticates the server, but it doesn\u2019t encrypt the browsing session itself.<\/p>\n\n\n\n Standard HTTPS<\/a> authenticates the server to the client. TLS can also require a client certificate, but this is optional and more common in controlled environments where a service needs to authenticate connecting users or devices.<\/p>\n\n\n\n PKI gives systems a reliable basis for recognizing digital identities. This means several security functions can work from a shared trust model instead of establishing trust independently.<\/p>\n\n\n\n Beyond the web example above, PKI also appears in:<\/p>\n\n\n\n VPN protocols such as Internet Key Exchange version 2\/Internet Protocol Security (IKEv2\/IPsec) can use X.509 certificates to authenticate VPN peers.<\/strong> In a site-to-site VPN<\/a>, this can mean authenticating the gateways at each end of the connection. Remote-access deployments can also use certificates to authenticate managed devices or users.\u00a0<\/p>\n\n\n\n OpenVPN can also use certificates through TLS to authenticate VPN endpoints. An organization might issue individual client certificates to employees or devices, while the VPN server presents its own certificate during connection setup.<\/p>\n\n\n\n Certificate-based PKI isn\u2019t universal across VPN protocols. WireGuard, for example, identifies peers by their public keys rather than using X.509 certificates or a CA hierarchy.<\/p>\n\n\n\n PKI certificate management covers the ongoing work needed to keep certificates organized and usable after they\u2019re issued. It often follows four stages:<\/p>\n\n\n\n PKI classifications include trust (public vs. private), operation (managed vs. self-managed), and hosting (cloud vs. on-premise). These dimensions are independent, so a private PKI can still be cloud-hosted or fully self-managed.<\/p>\n\n\n\n Public PKI uses CAs whose root certificates are already recognized by common browsers or operating systems.<\/strong> This makes it suitable for internet-facing services that need to work on users\u2019 devices without requiring custom certificate installation.<\/p>\n\n\n\n CAs that participate in public trust programs must follow the requirements set by the relevant browser or operating system vendor. \u201cPublic\u201d describes who can recognize the certificates by default. It doesn\u2019t mean the CA infrastructure is accessible.<\/p>\n\n\n\n Private PKI creates a trust system for a controlled environment.<\/strong> The organization distributes its own root certificate to the devices or applications that should recognize certificates issued under that PKI.<\/p>\n\n\n\n Systems configured to recognize the organization\u2019s root trust private PKI certificates. External browsers and unmanaged devices won\u2019t trust them by default.<\/p>\n\n\n\n How you deploy PKI depends on your resources, expertise, and how much control you need over the infrastructure. These are your main options:<\/p>\n\n\n\nWhat Are Public and Private Keys?<\/h3>\n\n\n\n
\n
What Is a PKI Certificate?<\/h3>\n\n\n
<\/figure>\n<\/div>\n\n\n\n
What Are the Main Components of PKI?<\/h3>\n\n\n\n
\n
How Does PKI Work?<\/h2>\n\n\n\n
How Is a Certificate Issued?<\/h3>\n\n\n\n
\n
How Do Systems Validate a Certificate?<\/h3>\n\n\n
<\/figure>\n<\/div>\n\n\n\n
The Difference Between PKI and SSL\/TLS<\/h2>\n\n\n\n
Why Is PKI Important in Cybersecurity?<\/h2>\n\n\n\n
\n
What Is PKI Used For?<\/h2>\n\n\n
<\/figure>\n<\/div>\n\n\n\n
How Do VPNs Use PKI?<\/h3>\n\n\n\n
How Does PKI Certificate Management Work?<\/h2>\n\n\n\n
\n
Types of PKI Solutions<\/h2>\n\n\n\n
Public PKI vs. Private PKI<\/h3>\n\n\n\n
Managed, Cloud, and Self-Hosted PKI<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2026\/08\/Who-Does-the-Certificate-Authenticate_-11-1-856x1024.png\")
<\/figure>\n<\/div>\n\n\n