Learning outcomes
- Separate path construction, path validation, and service-identity matching.
- Trace a leaf and intermediate chain to a locally trusted anchor.
- Test name, time, usage, constraint, algorithm, and revocation failures.
- Plan trust-anchor and intermediate rotation without accepting an unintended issuer.
Protocol roles
The end entity presents a leaf certificate and usually one or more intermediate certificates. A certification authority signs certificates under policy. The relying party constructs a candidate path and validates it to a trust anchor that local configuration already accepts. The application then verifies that the leaf represents the service or client identity required for this connection.
A trust anchor is an input to validation, not another untrusted certificate discovered from the peer. The peer can supply intermediates. It cannot decide which root the relying party trusts. RFC 5280 Section 6 defines the path-validation algorithm. RFC 9525 covers service-identity matching for TLS clients.
Message flow
- The TLS peer presents the leaf first and can send intermediate certificates after it. The root is often omitted because trust anchors are distributed independently.
- The relying party finds a candidate chain from the leaf through intermediates to one configured trust anchor.
- It verifies every certificate signature and applies validity time, basic constraints, path length, name constraints, certificate policies, and critical-extension processing.
- It checks that the leaf key usage and extended key usage permit the intended TLS role.
- It applies local algorithm and key-size policy.
- It matches the intended reference identity against the allowed certificate identity form. For a DNS service, this is normally a subject alternative name. A chain can be valid while the service name is wrong.
- It applies the deployment's revocation policy and then accepts or rejects the peer.
Path building can find several candidates. Validation must not turn this convenience into trust expansion. Constrain issuer retrieval, alternate chains, cross-signs, and enterprise roots to the trust model for the route.
Validation and failure cases
Build deterministic tests with generated certificates or a test PKI:
- A valid chain for the expected name succeeds.
- A valid chain for another name fails identity matching.
- A chain ending at an unknown root fails.
- A missing intermediate fails unless the client obtains that exact intermediate through an approved method.
- An expired or not-yet-valid leaf fails under the defined clock policy.
- An intermediate marked
CA:FALSE, a path-length violation, or a name-constraint violation fails. - A leaf without the required server or client authentication use fails.
- An unrecognized critical extension fails.
- A weak or locally prohibited signature algorithm fails.
- A revoked certificate fails according to the stated revocation and outage policy.
RFC 9846 Section 4.5.1.3 adds TLS-specific certificate requirements and points detailed validation to RFC 5280. Keep the two layers explicit: TLS carries and proves possession of the certificate key; PKIX and service-identity rules decide whether that certificate is acceptable.
Design tradeoffs and residual risk
Online revocation checks can reduce the accepted life of a revoked certificate, but they add privacy, availability, and freshness dependencies. Soft-fail behavior improves availability while accepting more revoked credentials during an outage. Short certificate lifetimes reduce this window but do not remove the need for compromise response.
Large system trust stores improve public compatibility but accept many issuers. A route-specific private trust bundle narrows authority but requires deliberate distribution and overlap during rotation. Cross-signed chains help migration but can create unexpected valid paths.
Residual risk includes compromised roots, malicious issuance, delayed revocation, clock error, incomplete inventory, and endpoints that validate chains but skip names. Certificate transparency can help detect public mis-issuance. It does not make a bad certificate invalid by itself.
Pomerium boundary
Pomerium can present configured certificates to clients and validate certificates for configured upstream or client-certificate connections. Operators own the trusted authorities, accepted names, usage policy, private keys, revocation behavior, and rotation procedure. Route authorization remains separate from certificate validation.
Exercise
Choose one upstream TLS route. Record the intended DNS name, trust anchor, expected intermediate, leaf usage, renewal owner, and revocation policy. Use a test endpoint to present ten chains that cover the validation and failure cases above. Record the exact reason for each result.
Then rotate the intermediate or root in a staging trust store. Add new trust before new issuance, verify both paths during the planned overlap, remove old issuance, and prove that the retired chain fails after the overlap ends.
Evaluation checklist
- Is trust anchored in local policy instead of a certificate supplied by the peer?
- Are path validation and service-name matching separate mandatory checks?
- Do constraints, critical extensions, key use, algorithms, and time fail closed?
- Is revocation behavior explicit during responder failure?
- Can operators rotate an issuer without indefinite trust overlap or an outage?
Next learning unit
HTTPS and TLS
Explain HTTPS as HTTP over an authenticated, encrypted TLS channel with explicit names, endpoints, and termination boundaries.
