Certificate Chain of Trust
Certificate validation links a peer identity to a configured trust anchor through signed certificates.
Jul 11, 2026
A certificate chain lets a TLS client validate that a public key is authorized for a service identity.
A typical chain contains:
- An end-entity certificate for the server.
- One or more intermediate CA certificates that signed the certificate below them.
- A root CA certificate configured locally as a trust anchor.
The server normally sends its end-entity certificate and required intermediates. It does not need to send the root because the client must already trust that root independently.
Validation
For HTTPS, a client must perform both:
- path validation: signatures, validity periods, constraints, key usage, and a path to a configured trust anchor;
- service identity validation: match the requested DNS name or IP address against the appropriate
subjectAltNameentry.
A successful path to a trusted root does not make a certificate valid for every hostname. Modern service-identity validation uses subjectAltName; a Common Name alone is not the deployment target for new certificates.
Private Trust
A self-signed certificate is not automatically unsuitable for production. A private root CA can be a valid trust anchor for controlled internal systems when its certificate is distributed securely, its private key is strongly protected, and rotation and revocation procedures exist.
Installing an individual server certificate as a trust anchor couples clients directly to that certificate and complicates rotation. A managed private CA or workload-identity system is usually easier to operate.
Revocation And Expiry
Expiry is checked locally. Revocation may use CRLs or OCSP, but client behavior, network availability, privacy, and soft-fail policies limit the guarantee. Short-lived certificates reduce dependence on revocation infrastructure but require reliable automated renewal.