How trust is built
The browser ships a set of root certificates (trust anchors). Your server presents a cert signed by an intermediate CA, which is signed by a root. The browser walks this chain up to a trusted root before it trusts you.
Certificate chain
| Role | Note |
|---|---|
| Root | Self-signed, preinstalled in OS or browser; private key never leaves |
| Intermediate | Signed by root, signs server certs, protects the root key |
| Server cert | Your domain cert, signed by an intermediate |
Two common setup mistakes
- Sending only the server cert: the browser cannot complete the chain and warns "not trusted"; you must serve the intermediates too;
- Wrong order: put the leaf cert first, intermediates after; some clients reject a wrong order.
Verify
Use openssl s_client -showcerts to see whether the chain served is complete. The cert itself is ASN.1 and can also be inspected as Base64.
Try it
Inspect Base64 encoding: Base64.
Real-world cases: three failures where "the cert looks fine"
- Missing intermediates: only the leaf certificate is installed; desktop browsers patch the chain, but some Android builds and CLI clients report
unable to get local issuer certificate. Always deploy the full chain. - Root rotation not propagated: when the CA rotates its root, un-updated trust stores and server chains start failing on some clients. Track CA rotation notices and keep a transition window.
- Internal CA without distributing the root: switching internal services to self-signed certificates without installing the root on clients triggers a fleet-wide alert. Distribute the root to every client trust store.
FAQ
What is in a certificate chain? The leaf (site) certificate, intermediate certificates, and ultimately a root; the root lives in client trust stores and is not sent over the connection. Why do browsers work while scripts fail? Browsers attempt chain building or let the user click through; CLI clients strictly verify chain and hostname. What is a trust anchor? The root (or intermediate) certificate trusted unconditionally in a trust store — the starting point of verification. How do I self-check quickly? Use openssl s_client -showcerts to see the chain the server actually sends and confirm intermediates are present.
Routine certificate operations checklist
Certificate problems are rarely technical mysteries; they are process gaps. Turning these into routine actions prevents most outages.
- Register every expiry centrally: gather all expiry dates in one place with alerts, including easily forgotten internal services, test environments and third-party callback domains.
- Automate renewal and verify it: after renewal, confirm the new certificate is actually in use rather than trusting a successful job — the common failure is a renewed certificate the service never reloaded.
- Check chain completeness on release: use a command-line tool after each deploy to confirm the served chain includes intermediates, so problems do not surface only on some clients.
- Keep a rollback path: when replacing a certificate or issuer, retain the old one for a period until the new one works everywhere.
- Record trust store differences: clients trust different root sets, especially mobile and legacy devices — cover them in the canary.
A suggested triage order
When certificate errors appear, work from the client error code, to the chain actually served, to hostname and validity, and finally to the client trust store. Most issues resolve in the first two steps.
Fitting into automated delivery
Manage certificates and keys as infrastructure as code so issuance, deployment and renewal run through pipelines, avoiding unclear versions and omissions from manual uploads. Treat the files as secrets with access control and auditing, and never keep them in the same repository as application code.