How Does Public Key Infrastructure Work?

Public key infrastructure, or PKI, is a collection of technologies, policies, and processes for managing public-private key pairs and digital certificates. Its primary purpose is to reliably associate a public key with the identity of a website, user, device, or application—and to withdraw that trust if the certificate or private key is no longer secure.

According to the NIST definition of PKI, PKI includes more than certificate authorities. It also covers the policies, processes, servers, software, and workstations required to issue, maintain, and revoke certificates.

PKI is used for website authentication, enterprise device access, code signing, encrypted email, and mutual TLS communication between servers.

How Are Public Keys, Private Keys, and Digital Certificates Related?

PKI is based on asymmetric cryptography. Each participant generally has a key pair:

• A private key is kept secret by its owner and used for signing, authentication, or certain decryption operations.
• A public key can be distributed openly and used to verify signatures, encrypt information, or participate in key agreement.

Simply obtaining a public key does not prove that it belongs to a particular website or device. An attacker could generate another key pair and impersonate the intended party.

A digital certificate addresses this problem. It acts like an electronic identity document signed by a trusted authority and usually contains:

• The certificate holder’s name or domain;
• A public key;
• The issuing certificate authority;
• A serial number;
• A validity period;
• Permitted key uses;
• Additional extensions;
• The certificate authority’s digital signature.

The X.509 certificates and certificate revocation lists commonly used on the internet are described in RFC 5280.

What Are the Core Components of PKI?

Component	Primary role
Root certificate authority	Acts as the trust anchor and signs subordinate CA certificates
Intermediate certificate authority	Issues certificates to servers, users, and devices on behalf of the root
Registration authority	Verifies certificate applicants and their identity information
Certificate holder	Uses a certificate and its corresponding private key
Certificate repository and status services	Publish certificates, revocation lists, and certificate status
Relying party	Validates a certificate and decides whether to trust its holder
Trust store	Contains the root certificates already trusted by a system

The NIST specification for PKI components identifies certificate authorities, registration authorities, certificate holders, validating clients, and certificate repositories as core PKI components.

Enterprises commonly keep the root CA offline and use intermediate CAs for routine certificate issuance. This reduces the root private key’s exposure to network-based threats.

How Is a Digital Certificate Issued?

A typical certificate issuance process works as follows:

1. A user, server, or device generates a public-private key pair.
2. The private key remains in secure local storage.
3. The applicant creates a certificate signing request containing the public key and identity information.
4. A registration authority or CA verifies the applicant’s identity.
5. The CA verifies that the applicant possesses the corresponding private key.
6. The CA signs the certificate using its own private key.
7. The certificate is installed on the server, device, or application.
8. The system records the certificate owner, validity period, and permitted use.

A certificate signing request can contain the public key, but it should never contain the applicant’s private key. If that private key is compromised, an attacker may be able to impersonate the certificate holder even while the certificate remains valid.

How Does a Certificate Trust Chain Work?

Most end-entity certificates are issued by intermediate CAs rather than directly by a root CA. A typical trust chain therefore looks like this:

Trusted root certificate → Intermediate certificate → Website or device certificate

When a browser connects to an HTTPS website, the server sends its certificate and the required intermediate certificates. The client then checks:

1. Whether the certificate chain leads to a trusted root;
2. Whether each certificate’s digital signature is valid;
3. Whether the certificates are within their validity periods;
4. Whether the domain matches the identity in the certificate;
5. Whether the certificate permits server authentication;
6. Whether the certificate has been revoked;
7. Whether the server possesses the corresponding private key.

In TLS 1.3, the server sends its certificate chain and signs the handshake data using the corresponding private key. This proves that it controls that private key. RFC 8446 defines this certificate and signature verification process.

If the checks succeed, the client can trust the server’s identity and continue establishing the encrypted connection.

Does PKI Encrypt All Communication Directly?

Not necessarily. In HTTPS and TLS, digital certificates are primarily used to authenticate a server or client. After the handshake, the parties generally encrypt application data using temporary symmetric keys, which are better suited to processing large amounts of data.

The primary functions of PKI include:

• Authenticating websites, users, and devices;
• Distributing trusted public keys;
• Supporting digital signature verification;
• Establishing trust for secure communication;
• Managing certificate issuance, renewal, and revocation.

PKI is a trust and key-management infrastructure, not a single encryption algorithm.

What Happens When a Certificate Expires or a Private Key Is Compromised?

Every certificate has a validity period. Before it expires, the system must request and deploy a replacement.

If a private key is compromised, a device is lost, identity information changes, or a certificate is issued incorrectly, the certificate should be revoked rather than left active until expiration.

Two common certificate-status mechanisms are:

• Certificate Revocation List (CRL): A list of revoked certificates periodically published by the CA.
• Online Certificate Status Protocol (OCSP): A protocol that allows clients to request the status of a specific certificate.

RFC 6960 defines OCSP, which allows a client to check certificate status without downloading an entire revocation list.

Revocation is not automatically reliable in every environment. A client may be unable to reach the status service or may not strictly enforce status checking. Enterprises can reduce this risk through shorter certificate lifetimes, automated renewal, and continuous monitoring.

What Is the Difference Between Public and Private PKI?

Comparison	Public PKI	Private PKI
Trust scope	Browsers, operating systems, and public users	Internal systems and approved partners
Certificate authority	Public CA	Enterprise-controlled or dedicated CA
Common uses	Public websites and internet services	Employees, devices, internal services, and nodes
Root distribution	Usually included in system trust stores	Installed and managed by the enterprise
Policy control	Subject to public CA requirements	Can use customized identity and certificate policies
Management responsibility	Shared between the public CA and customer	Primarily handled by the enterprise

Public websites generally require certificates issued by CAs already trusted by browsers. Internal services, devices, and wallet nodes can use private PKI, but the enterprise must securely distribute root certificates and protect the CA’s private keys.

How Is PKI Used in Crypto Wallet Infrastructure?

PKI keys and blockchain wallet keys serve different purposes.

Wallet private keys or MPC key shares authorize blockchain transactions. PKI certificates authenticate the servers, devices, and nodes within the wallet infrastructure.

In an institutional wallet system, PKI can help:

• Authenticate MPC nodes;
• Establish mutual TLS between signing nodes;
• Restrict wallet network access to authorized devices;
• Authenticate message relay services;
• Manage certificates for servers and signing terminals;
• Revoke communication access for lost or retired devices;
• Provide machine identities for internal APIs.

These key types should remain separate. Obtaining a node communication certificate should not grant blockchain signing authority. Similarly, controlling a wallet key share should not provide permission to issue certificates.

What Are the Main Risks of PKI?

Certificate Authority Compromise

If a root or intermediate CA private key is compromised, an attacker may be able to issue fraudulent certificates. NIST has published guidance for responding to CA compromises, emphasizing that certificate authorities are themselves high-value targets.

Weak Identity Verification

Even if the cryptographic algorithms are secure, the trust model fails if a certificate is issued to the wrong person, device, or service.

Insecure Private Key Storage

Certificates can be public, but their corresponding private keys must remain protected. High-value CA keys can be stored in hardware security modules or isolated environments.

Certificate Expiration

Expired certificates can unexpectedly interrupt websites, APIs, and internal services. Enterprises need a certificate inventory, expiration alerts, and automated renewal processes.

Failed Revocation Checking

Revoking a certificate does not guarantee that every client will immediately stop trusting it. Short-lived certificates and rapid replacement processes can help reduce this risk.

Incorrect Trust Store Configuration

Installing an unauthorized root certificate may allow an attacker to issue certificates that internal systems trust. Adding or removing root certificates should require strict approval.

How Should Enterprises Manage PKI?

Enterprises should consider the following controls:

• Keep the root certificate authority offline;
• Use intermediate CAs for routine certificate issuance;
• Protect CA private keys with hardware security modules;
• Maintain a complete certificate and key inventory;
• Assign a clear owner and purpose to every certificate;
• Automate certificate requests, renewal, and deployment;
• Restrict certificate issuance using least privilege;
• Separate identity verification, certificate approval, and CA administration;
• Monitor expiring, unusually issued, and revoked certificates;
• Test CA outages, private key compromise, and large-scale certificate replacement;
• Retain logs for certificate requests, issuance, renewal, and revocation;
• Prepare certificate migration and replacement plans for provider outages.

The NIST TLS certificate management practice guide emphasizes certificate inventories, ownership, renewal, revocation, and continuous monitoring.

Frequently Asked Questions

Are PKI and public-key cryptography the same thing?

No. Public-key cryptography provides key pairs, encryption, and digital signature algorithms. PKI associates public keys with identities and manages the certificate lifecycle.

Does a digital certificate contain a private key?

Usually not. A certificate contains a public key and identity information. The certificate holder must store the corresponding private key separately and securely.

Why Is a Root Certificate Trusted?

Root certificates are placed into trust stores through operating systems, browsers, device management, or enterprise configuration. Their trust comes from controlled distribution and management, not because a self-signed root certificate proves its own trustworthiness.

Should a Root CA Remain Online?

A high-value root CA generally does not need to remain online. An enterprise can keep the root CA offline and use intermediate CAs for routine certificate issuance.

Does a Blockchain Wallet Require PKI?

An individual blockchain wallet can use public-private key pairs and signatures without X.509 PKI. However, institutional wallet servers, APIs, and MPC nodes can use PKI to authenticate devices and secure communications.

Does a Valid Certificate Guarantee That a System Is Secure?

No. A valid certificate only shows that a public key was signed by the relevant CA. The system must still protect private keys, verify identities, restrict permissions, and validate communication or transaction contents.

Conclusion

Public key infrastructure uses digital certificates to connect public keys with the identities of websites, users, devices, and services. Its core processes include key generation, identity verification, certificate issuance, trust-chain validation, certificate status checking, renewal, and revocation.

PKI security depends not only on cryptographic algorithms but also on certificate authorities, private key protection, identity verification, trust stores, and certificate lifecycle management.

In institutional wallet infrastructure, PKI can authenticate servers and MPC nodes, while MPC protects blockchain transaction signing. Safeheron can help enterprises deploy the relevant nodes, certificates, and MPC capabilities within privately controlled environments. To explore an approach suited to your wallet architecture and security requirements, contact Safeheron to schedule a consultation.