When an application connects to an HTTPS server, it needs to verify that the server is really who it claims to be. Encrypting the connection is not enough. Without identity verification, an attacker could present their own encryption key and intercept the communication.
This is one of the problems that Public Key Infrastructure (PKI) solves.
PKI provides a way to establish trust between systems using digital certificates, cryptographic keys, and trusted authorities. It is commonly used in HTTPS, mutual TLS (mTLS), enterprise authentication, and secure communication between services.
To understand PKI, we need to understand how certificates are issued, how applications trust them, and what happens when a certificate should no longer be trusted.
Public and Private Keys
PKI uses asymmetric cryptography, which involves two related keys: a public key and a private key.
The public key can be shared with other systems. The private key must remain protected and accessible only to its owner.
For digital signatures, the private key is used to sign data, while the public key is used to verify the signature. This allows another system to check that the signature was created using the corresponding private key and that the signed data has not been modified.
For example, during a TLS connection, a server can prove possession of its private key by signing handshake data. The client verifies that signature using the public key in the server’s certificate.
But there is still one problem. How does the client know that the public key actually belongs to the intended server?
That is the purpose of digital certificates.
Digital Certificates and Certificate Authorities
A digital certificate connects an identity to a public key. The most common format is X.509, which is used by TLS and many enterprise security systems.
A typical certificate contains information such as the subject, public key, issuer, validity period, serial number, and digital signature. For HTTPS, the Subject Alternative Name (SAN) extension identifies the DNS names or IP addresses for which the certificate is valid.
A Certificate Authority (CA) is responsible for issuing and signing certificates. Before issuing one, the CA performs validation appropriate to the certificate type and its policies.
Consider an API hosted at api.example.com. The server has a private key and a corresponding certificate issued by a CA. When a client connects, the server presents its certificate. The client then checks whether the certificate is valid for api.example.com and whether it can establish trust in the issuing CA.
Most publicly trusted certificate hierarchies use an intermediate CA between the root CA and the server certificate.
The root CA is the trust anchor, while intermediate CAs issue certificates without requiring the root’s private key to be used for every issuance.
The client verifies the certificate signatures along the chain until it reaches a trusted anchor. A valid signature alone does not establish trust. The chain must also satisfy applicable constraints and validation rules.
Trust Stores: Where Trust Begins
A trust store contains certificates or trust anchors that an application accepts for certificate validation.
Operating systems, browsers, and application runtimes may maintain their own trust stores. This explains why a certificate can work in one environment but fail in another.
For example, a Java application may use a configured Java trust store, while another application uses the operating system’s certificate store.
When a TLS client validates a server certificate, it generally checks several things:
- The certificate matches the requested hostname.
- The certificate is within its validity period.
- The certificate chain leads to an accepted trust anchor.
- The signatures, algorithms, key usage, and certificate constraints satisfy validation requirements.
- Revocation status is checked according to the client’s policy and capabilities.
A common development mistake is disabling certificate validation when a connection fails.
For example, a developer may configure an HTTP client to accept any server certificate because the development environment uses a self-signed certificate.
That removes an important security check. An encrypted connection can still be established with an attacker-controlled server.
A better approach is to install the appropriate internal CA certificate into the application’s trust store, or configure a dedicated trust store for the development environment.
Certificate Revocation: CRLs and OCSP
Certificates have expiration dates, but sometimes they need to be invalidated before expiration.
A private key might be compromised, a certificate may have been issued incorrectly, or an organization may no longer be authorized to use it.
This is called certificate revocation.
Two commonly used mechanisms are Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP).
Certificate Revocation Lists (CRLs)
A CRL is a digitally signed list published by a CA that identifies revoked certificates, usually by serial number.
A client can download the CRL, verify its signature, and check whether the certificate appears in the list.
CRLs work without requiring a separate request for every certificate validation. However, they need regular updates, and large lists can consume bandwidth and storage.
The CRL also has freshness information, including when it was issued and when the next update is expected.
If an application relies on CRLs but does not refresh them properly, it may continue using outdated revocation information.
Online Certificate Status Protocol (OCSP)
OCSP allows a client to request revocation status information for a particular certificate.
An OCSP responder can return a status such as good, revoked, or unknown.
One detail worth understanding is that good does not guarantee that a certificate is valid for the requested hostname or that its entire chain is trusted. It generally means the responder has no revocation record for that certificate under the applicable response semantics.
OCSP responses are signed and include timing information that clients use to evaluate freshness.
OCSP stapling is another mechanism where the TLS server provides a previously obtained OCSP response during the handshake. This can reduce the need for the client to contact the responder directly.
Neither CRLs nor OCSP automatically guarantees that every client will reject a revoked certificate. Some clients use soft-fail behavior, where validation may continue if revocation information is unavailable. Others enforce stricter policies.
For developers building security-sensitive systems, revocation handling should be an explicit design decision rather than an assumption.
What Happens During an HTTPS Connection?
Consider a backend service calling https://api.example.com.
The client initiates a TLS handshake, and the server provides its certificate chain. The client validates that chain against its configured trust anchors, checks the server identity, and applies relevant certificate validation policies.
The server also proves possession of the private key corresponding to its certificate. With modern TLS, the handshake establishes symmetric encryption keys that protect subsequent application traffic.
Conceptual TLS connection flow. Several handshake messages are omitted for simplicity.
In mutual TLS, the server also requests a client certificate and validates the client’s identity. This is useful for service-to-service communication where both sides need certificate-based authentication.
Practical Considerations for Developers
PKI problems are often configuration problems rather than cryptographic problems.
An application may fail to connect because the server does not provide an intermediate certificate, the certificate does not match the hostname, or the client does not trust the issuing CA.
Certificate renewal also deserves attention. Replacing a certificate without updating the corresponding configuration or ensuring the correct private key is available can cause service failures.
For internal systems, using a private CA can be reasonable, but its trust must be distributed carefully. Adding a CA to a trust store means accepting certificates issued under that authority within the applicable validation rules.
Private keys need stronger protection than public certificates. Depending on the environment, this may involve restricted file permissions, secure key storage, hardware security modules (HSMs), or managed key services.
Finally, certificate expiration monitoring and revocation policies should be part of the operational design. A certificate that is correctly installed today can still cause an outage later if nobody monitors its expiration.
Conclusion
PKI is easier to understand when we separate its responsibilities.
Certificates bind identities to public keys. Certificate Authorities issue and sign certificates. Trust stores define which authorities an application accepts. CRLs and OCSP provide mechanisms for checking whether certificates have been revoked.
These components work together, but each solves a different problem.
For developers, the most useful thing is to understand what the application actually validates during a TLS connection. Once that is clear, certificate errors, trust store configuration, and revocation handling become much easier to troubleshoot.
The same understanding also helps when designing internal APIs, mutual TLS authentication, and other systems that depend on certificate-based trust.
Technical references
The article follows the general PKI and certificate-management concepts described in NIST guidance and related Internet standards. These are useful references for further reading:
