Your browser has never heard of most websites, yet it decides within milliseconds whether to trust their certificates. It can do that because it does not need to know the site. It only needs to know someone who vouches for the site, and someone who vouches for them, until the line of introductions ends at a name it already holds on file. That line is a chain.
The system works well enough that most people never think about it, and it fails in ways that look arbitrary: a site that opens on your laptop and throws a warning on a customer's phone, a script that refuses to connect to an address your browser loads happily. Nearly all of those cases come down to how the chain is built or how a particular device reads it.
This piece explains who sits at the top, why there are links in the middle, what your server has to send, and what happens on the rare occasion an authority loses the trust it was given.
Roots, intermediates and your certificate
At the top sit root certificates, which belong to certificate authorities. A root is a self-signed certificate: it vouches for itself, and the only reason anyone believes it is that a browser or operating system maker decided to include it in a list. That list is called a root store. Microsoft, Apple, Mozilla and Google each maintain one and set their own standards for who gets in and who stays in. Linux distributions and many programming languages ship a copy of the Mozilla list, which is why a command line tool on a server and a browser on a desktop usually agree.
Authorities do not sign website certificates directly with the root. The root key is the most valuable thing the authority owns, so it is kept offline, often in a hardware module in a locked room, and brought out only for ceremonies where it signs new intermediates. The day-to-day work is done by intermediate certificates, signed by the root, which in turn sign the certificates for sites. Roots commonly last twenty years or more. Intermediates last a few years. The certificate for your site lasts a matter of months.
When you visit a site, the server presents its own certificate plus the intermediate that signed it. The browser checks that the site's certificate was signed by the intermediate, that the intermediate was signed by a root, and that it holds that root in its store. Each link is a signature that can be checked mathematically. If one link is missing or wrong, the chain does not complete and the browser has to give up.
Why your server must send the chain
The browser has the roots. It may not have the intermediates. If your server sends only its own certificate, some clients can find the missing piece and some cannot, and you get the maddening situation where the site works on your laptop and fails on a phone or in a script.
Why the split? Certificates contain a field called Authority Information Access that says where the issuer's certificate can be downloaded. Some browsers follow it and repair the chain on their own. Others keep a cache of intermediates they met on earlier sites, so a visitor who has been to another site using the same intermediate sees no problem. Many command line tools, libraries and older devices do neither, and report an unknown issuer.
The cure is to install what your authority calls the full chain: your certificate followed by the intermediate or intermediates, in that order. The root is left out because the client already has it, and sending it only adds bytes to every handshake. Most automated tooling produces the right file for you. With Certbot, for instance, the file named fullchain.pem is the one to serve, and cert.pem on its own is the trap.
A worked example of a broken chain
A small shop owner installs a new certificate by hand. The authority emails a zip file with three files: the site certificate, a file called intermediate, and a root. In the hosting panel there are boxes for the certificate, the private key and "CA bundle". She pastes the site certificate and key, and leaves the bundle blank because it looks optional.
The padlock appears when she checks on her own computer. A week later a customer complains that the mobile app which reads the shop's product feed has stopped working, and a courier's system is rejecting webhook calls. The browser was fine because it had seen that intermediate on other sites. The app and the courier's software did not have it, and had no way to fetch it.
The fix takes two minutes: paste the intermediate into the CA bundle box and save. The diagnosis is what takes time, because every test she tried from her own machine passed. This is the usual shape of the problem, and the reason this guide keeps pointing you to a tool that remembers nothing.
What happens when an authority misbehaves
Trust can be withdrawn. Browsers and operating system vendors audit the authorities in their root stores, and the rules they hold them to are strict: validate who is asking before issuing, log everything, respond quickly to reports. There have been cases where an authority made repeated mistakes, or failed to be honest about them, and a browser maker removed it from the store. The removal does not happen overnight. It follows a published schedule, usually staged over months so that site owners have time to replace the certificates.
Every certificate that authority had issued then stopped working on the agreed dates, and its customers had to get new ones elsewhere. That power is the main check on the whole system. It is also why authorities take compliance seriously: their business depends entirely on their roots staying in the stores.
A different issue is old devices. Roots eventually expire, and new roots take years to be added to every phone, television and embedded gadget. Around late 2021, an old widely used root expired, and devices that lacked the newer roots stopped trusting sites that relied on it. If you support customers on very old equipment, expect some chain trouble that nothing on your server can fix.
Transparency and revocation
Publicly issued certificates are logged in open Certificate Transparency logs. Major browsers expect a certificate to carry proof that it was logged, and anyone can search the logs for certificates issued for their domain, then spot a mistaken or malicious one. A certificate that was never logged will not be accepted by the browsers that require it, which makes secret misissuance much harder.
Revocation, the ability to cancel a certificate before it expires, exists but is patchy in practice. Checking a revocation list or asking an online responder costs time and can fail, and a browser that insists on an answer would break sites whenever the responder is down. So many clients check loosely or not at all. That is a large part of why certificate lifetimes are getting shorter. The maximum is already well under a year, and the industry has agreed to step it down further over the next few years. A stolen key matters for less time if the certificate expires soon anyway, and automated renewal makes the shorter life painless.
It is also why you should search those logs for your own domain from time to time. Seeing a certificate you did not request is worth investigating. It may be a colleague or a forgotten service using the domain, or it may be someone who gained control of a DNS record or an email address.
What the chain does and does not tell you
A valid chain proves that an authority the browser trusts agreed to issue a certificate for this name to whoever asked. How hard the authority checked depends on the kind of certificate. The common automated kind only proves that the applicant controls the domain, usually by placing a file on the site or a record in DNS. Organisation validated certificates add a check on the company behind the request, and browsers no longer make much visual fuss about the difference.
So the padlock tells you the name is right and the traffic is private. It does not tell you the business is legitimate, and a phishing page on a lookalike domain can hold a perfectly valid certificate. If you want to teach colleagues or customers one habit, make it reading the domain name carefully rather than trusting the lock icon.
For site owners, the practical side is simpler: the chain is a delivery problem, not a security problem. Get the full file onto the server, renew before expiry, and test from a client that has no memory of earlier visits.
Where this differs on shared, VPS and managed hosting
| Hosting type | Who builds the chain | What you do |
|---|---|---|
| Shared, with automatic certificates | The host's panel installs and renews it | Nothing, apart from checking after a move |
| Shared, with a certificate you bought | You supply certificate, key and CA bundle | Paste the intermediate too, and again at renewal |
| VPS or dedicated, with an ACME client | The client writes a full chain file | Point the web server at the full chain file |
| Managed WordPress or CDN in front | The platform terminates TLS | Check the platform's edge, not just the origin |
The CDN case catches people out. If a content delivery network sits in front of your site, the certificate that visitors see belongs to the network's edge, while a second certificate on your own server only matters for the connection between the two. Test both ends.
Loose ends
Do I need to send the root certificate too?
No. A client that does not already trust the root will not trust it just because the server offered it. Leave it out.
Why does my company laptop show a different issuer?
Some workplaces and security products inspect encrypted traffic by installing their own root on managed devices and re-signing connections. The browser trusts it because the machine's owner put it in the store. At home, on a personal device, you would not expect to see it.
Is a free certificate less trusted than a paid one?
No. Trust comes from the authority's root being in the stores, not from the price. What differs is the support, the warranty and the validation level, none of which changes how the browser treats the padlock.
How often should I look at the logs for my domain?
Every few months is enough for a small site, or whenever you change DNS provider, hosting or email setup. Some authorities and monitoring services will also email you when a new certificate appears.