2.1 X.509 and PKI: Certificate Chains, Service Identity, and Revocation
Public-key bytes alone prove neither possession of the private key nor that the peer is api.example.com. Protocol steps such as handshake signatures prove possession; certificates and local trust policy bind that key to an identity. The role of PKI is to bind a public key to a named identity, its intended use, validity period, and issuance policy, and to enable clients to validate the entire chain of trust starting from a local trust anchor.
A Certificate Is a Signed Statement
A typical X.509 leaf certificate contains:
Subject public key
Serial number
Validity: notBefore / notAfter
Subject Alternative Name (SAN)
Key Usage / Extended Key Usage
Issuer
CA signature algorithm + signature
Other constraint extensionsCertificates do not include private keys. Publishing a private .key in an image can let anyone who obtains it impersonate the certificate subject. The .crt certificate itself is normally public.
TLS clients following RFC 9525 match service identity through subjectAltName without falling back to Subject Common Name; RFC 9525 supersedes RFC 6125. DNS names use dNSName. Literal IP addresses match SAN iPAddress entries, without inferring identity through reverse DNS. Wildcard entries are only valid as the full leftmost label, such as *.example.com; they match neither example.com nor a.b.example.com. Compromise of the private key shared for a wildcard certificate affects a broader set of hosts.
Chains Are Not Simple String Lists
Local trust anchor (root CA)
↓ Issues
Intermediate CA
↓ Issues
Leaf certificate: api.example.comClients typically store the root trust anchor locally, while the server sends the leaf certificate and any required intermediate certificates. The root certificate is generally not sent by the server; if an intermediate is missing, some clients will fail to construct a valid trust path.
Path validation involves at least the following checks:
- Whether each level's signature is valid and can be chained back to a locally trusted anchor;
- Whether the current time falls within each path certificate’s validity period, with the trust anchor handled under local policy;
- Whether
basicConstraintspermits the certificate to act as a CA; - Whether the path length, name constraints, and policy constraints are satisfied;
- Whether the key usage or extended key usage allows the intended purpose;
- Whether the leaf's SAN matches the client's independently constructed reference identity;
- Whether local policy requires revocation status, cryptographic strength, or other constraints.
"Correct certificate signature" is only one part of the process. The client must construct the expected identity from the URL or service configuration it intends to access, never use the name declared in the certificate as the expected identity.
Test a Valid Chain with the Wrong Name
Prepare leaf.pem from a controlled test CA, its required intermediates.pem, and independently selected trust anchors in roots.pem. The leaf should contain the SAN DNS:api.example.com and a server-authentication purpose. This command only reads local files; it does not install certificates in the system trust store.
openssl verify -CAfile roots.pem -untrusted intermediates.pem \
-purpose sslserver -verify_hostname api.example.com leaf.pemThe valid case should return leaf.pem: OK. Change the expected name to other.example.com, omit the required intermediate, or supply an unrelated root; each should fail. -verify_hostname does not configure every application’s identity policy; actual clients still need RFC 9525 settings. This command also performs no online revocation query or browser CT-policy check. See OpenSSL’s verification options for parameter details.
Trust Store Determines the Trust Boundary
Which trust anchor the certificate chain ultimately reaches is determined by the client's policy. Public Web PKI, enterprise private CAs, device manufacturer CAs, and service mesh CAs should not be blended together without clear boundaries.
Adding an enterprise root CA grants broad issuance trust unless devices further restrict its permitted purposes or namespaces. Private PKI systems must restrict intermediate certificate names and purposes, protect offline root keys, limit the authority of online issuing CAs, and establish certificate inventories with revocation capabilities.
Self-signed certificates are not inherently insecure; the issue lies in how trust is distributed and updated. Development environments can safely install a controlled local CA; production clients should never rely on "ignoring all certificate errors" to support self-signed certificates.
Revocation Mechanisms Have Availability Trade-offs
Certificate expiration is a predictable failure, while private key compromise requires proactive revocation. Common mechanisms include:
- CRL: Periodically download a list of revoked serial numbers, simple but potentially large and not sufficiently real-time;
- OCSP: Query a certificate's status online, adding privacy and availability dependencies;
- OCSP stapling: The server includes a status response signed by the issuing CA or an authorized OCSP responder, reducing client-side queries;
- Short-lived certificates: Reduce the exposure window after compromise, but require highly reliable automated issuance.
Different clients handle soft failures, hard failures, and stapling in distinct ways. You cannot assume that "the CA provides OCSP" guarantees end-to-end revocation effectiveness. Must-Staple has its intended effect only on clients that implement and enforce it. Before adopting it, evaluate outages caused by failed response updates. Short lifetimes limit certificate acceptance time; they do not revoke a compromised certificate immediately.
Certificate Transparency Ensures Discoverability
Certificate Transparency (CT) uses a public, auditable, append-only log to record public certificates or pre-certificates. Domain owners can monitor for unauthorized issuance, and browsers can require SCTs from qualifying logs under their own policies. An SCT is a signed promise of inclusion within a deadline, not proof that inclusion has already occurred; checking actual inclusion requires an inclusion proof.
CT does not prevent CA misissuance or substitute for client-side hostname and path validation. Instead, it makes misissuance more detectable and traceable, necessitating alerting, revocation, and emergency certificate rotation procedures.
Pinning Can Cause Availability Failures
Fixing a client to a single leaf certificate causes widespread disconnections during normal certificate rotation, CA switching, or emergency re-signing. In high-risk, closed environments where pinning is absolutely necessary, only design-approved public key sets or trust anchors should be pinned, with overlapping keys, backup pins, and a signed update path in place to ensure resilience.
Browser applications typically rely on platform-based Web PKI and Certificate Transparency (CT), rather than implementing pinning mechanisms like HPKP themselves. Identity validation failures must default to termination, never allowing a "continue anyway" prompt that places the burden of understanding certificate chains on end users.
Operations Checklist
- Does the SAN exactly cover the identities in use, rather than relying on overly broad wildcards?
- Does the service send the complete intermediate chain?
- Is the private key exportable? Who can access it, and is there audit logging of its usage?
- Are the expiration dates of the certificate, intermediate certificates, and trust anchor separately monitored?
- Are the cryptographic algorithms, key usage, extended key usage (EKU), and certificate purposes consistent and aligned?
- How long does it take to revoke, reissue, publish, and validate a certificate after a private key compromise?
- How does the system behave when client clocks are out of sync or when the CA or OCSP service is unavailable?
Continue with TLS 1.3 Handshakes and Automated Rotation.