Certificates have a reputation for being obscure, and it is undeserved. The cryptography underneath is genuinely difficult. The trust model on top of it is not — it is the same arrangement that lets you land in a country you have never visited and be waved through by an official who has never met you.
Once you see that, the error messages stop being noise and start telling you exactly which link in the chain is broken.
Start with the vault
Somewhere in every country there is a central authority responsible for passports. It does not sit at an airport issuing documents to the public. Its job is to hold the master authority and to delegate it carefully.
In certificates this is the root certificate authority. Its private key is the most sensitive object in the entire system, and it is treated accordingly: held offline in a hardware security module, in a safe, in a room with cameras, and brought out for ceremonies that happen rarely and are witnessed and recorded.
The crucial point is that you never verify the root. Your laptop, phone and browser ship with a list of roots they already accept — the trust store — in the same way border agencies maintain a list of countries whose passports they recognise. Trust in the root is pre-agreed and built in. Everything else hangs off it.
Then the issuing office
The central authority does not print your passport. A regional office does, operating under delegated authority, and that delegation is itself documented and signed.
That office is the intermediate certificate authority, and it exists for one overriding reason: to keep the root out of harm’s way. Day-to-day issuance is high volume, automated and exposed. If the key doing that work is ever compromised, you want to be able to revoke it and stand up a replacement.
Now imagine the alternative. If the root itself signed every certificate directly and was compromised, the only remedy would be removing that root from the trust store of every device on earth — every laptop, every phone, every embedded controller, every appliance that will never receive another update. That is not a recovery plan. The intermediate is the fuse in the circuit.
And finally the passport itself
Your passport names you, specifically, and expires on a stated date. It is not a general statement about your country; it is a narrow claim about one holder, for a limited period.
That is the leaf certificate, sometimes called the end-entity certificate. It names one thing — www.example.com, or a set of names listed inside it — and it has a validity window measured in weeks or months, not years. It is signed by the intermediate, which was signed by the root.
Root — the country’s authority, pre-trusted, kept in a vault.
Intermediate — the issuing office, doing the daily work under delegated authority.
Leaf — your passport, naming one holder, with an expiry date.
What happens at the border
The officer does three things, quickly, and your browser does exactly the same three things in a few milliseconds.
- Is the document itself valid? Not expired, not tampered with, and it names the person standing here. The browser checks the signature, the dates, and whether the name on the certificate matches the address you typed.
- Who issued it, and were they entitled to? The passport says which office issued it; that office’s authority traces back to the central authority. The browser walks from leaf to intermediate to root.
- Is that authority on my list? If the root is in the trust store, the chain is complete and the connection proceeds. If not, you get a warning.
The errors you will actually meet
The missing intermediate — the one that wastes the most time
This is the classic. A site works perfectly in Chrome on your laptop and fails from a server with curl, from a Java application, or on an older Android device. Nothing is wrong with the certificate.
In passport terms: you presented a valid passport from a legitimate office, but you did not bring the paperwork proving that office was authorised, and this particular official does not happen to have a copy on the desk. Browsers often paper over this by caching intermediates they have seen before, or by fetching the missing one automatically. Most other clients do not. The server is supposed to send the intermediate along with the leaf, and when it does not, the failure is intermittent and maddening — which is exactly why it is so often misdiagnosed.
The rest of them
- Expired. Your passport ran out. Unarguable, and almost always an avoidable operational failure rather than a security event.
- Name mismatch. The passport is valid, but it belongs to somebody else. The certificate is for
example.comand you asked forwww.example.com. - Untrusted issuer. A perfectly real document from a country not on the officer’s list. Common with private internal authorities, where the fix is to distribute your own root to your own devices.
- Self-signed. A passport you printed at home. It may be accurate; nobody is vouching for it but you.
- Revoked. Reported lost or stolen, and cancelled before its expiry date. Checked through revocation lists or OCSP, with stapling to make it fast.
What a certificate does not tell you
This matters more than anything else on the page, and it is routinely misunderstood.
A valid certificate proves that the connection is encrypted and that the server genuinely controls the name you asked for. It proves nothing whatsoever about whether the people running it are honest. A passport confirms identity; it does not certify good character.
Phishing sites have valid certificates. They are free and automatic, so of course they do. The padlock means your connection to the fraudster is beautifully encrypted — which is why “look for the padlock” stopped being useful security advice years ago, and why the tells that matter are the ones in The Phishing Trap instead.
Your own authority: the staff badge
Many organisations run a private certificate authority for internal services. That is the company badge rather than the passport: perfectly valid inside the building, meaningless outside it, because only your own machines have been told to trust the issuer.
It is a sound approach, with two obligations attached. Your root has to reach every device that needs it, including contractor laptops and anything unmanaged — and you are now operating a certificate authority, which means protecting that root key with the seriousness the analogy implies.
Operating all this without 3am surprises
- Keep an inventory with expiry dates. Expired certificates cause more outages than attacks do, and they always expire at an inconvenient moment.
- Automate renewal. ACME and Let’s Encrypt solve the renewal problem rather than the cost problem, which is the more valuable of the two.
- Expect lifetimes to keep shortening. The industry is moving steadily towards shorter validity periods, which makes manual renewal untenable and automation mandatory.
- Test from outside a browser.
openssl s_client -connect host:443 -showcertswill reveal a missing intermediate that Chrome quietly hides. - Monitor expiry as an alert, not a diary note. Thirty days of warning, reaching somebody who can act.
- Never train people to click through warnings. If an internal service throws a certificate error every day, you have taught your staff that the warning is noise — and they will carry that habit to a site where it matters.
Encryption in transit is only half the job; the other half is knowing who is on the other end, which is the subject of Data Safeguards: From Storage to Transit.
The chain is only three links long: something kept in a vault, something doing the daily work, and the document in your hand. When a certificate error appears, it is telling you which of the three the other side could not prove.