You type your bank's address, the padlock appears, and you assume you're talking to who you think. But between your browser and that server there's a network you don't control, full of points where someone could impersonate the site. The real question isn't "is the connection encrypted?", but "am I encrypting with the party I actually want?". That's exactly the question digital certificates —and the infrastructure that backs them, the PKI— exist to answer.
The problem they solve
Asymmetric encryption lets a server publish its public key so anyone can encrypt messages that only it, with its private key, can read. Elegant —but it leaves a gaping hole.
Asymmetric encryption lets a server publish its public key, but a question arises that encryption alone does not answer: how do I know that public key is from who it claims to be, and not from an impostor who put themselves in the middle?
A digital certificate answers exactly that: it stamps an identity onto the public key, signed by someone you already trust.
Without certificates, an attacker in the middle of the path could hand you their public key while pretending to be the bank. You'd happily encrypt… straight to the attacker. The certificate is what breaks that trick: it ties the public key to a specific domain and backs it with a verifiable signature.
What a digital certificate is
A digital certificate is an electronic document that binds an identity
—a domain, for example bank.com— to its public key, and that is
signed by a trusted authority. That stamp is what gives it value: anyone
can claim to be bank.com, but not just anyone can produce a valid signature
from a recognized authority.
Inside, a certificate mainly contains:
- The domain (or domains) it's valid for.
- The site's public key.
- The validity dates —from when and until when—.
- The signature of the authority that issued it, which guarantees none of the above was tampered with.
All of that travels in a standard format called X.509 —the same one used by HTTPS, email or code-signing certificates—. You don't need to read it by hand; your browser interprets it for you in milliseconds.
Who signs: Certificate Authorities (CAs)
A Certificate Authority (CA) is an organization that browsers and operating systems trust by default. Its job is to verify requests and sign certificates with its own private key, putting its reputation behind every signature.
Your device ships with a preinstalled list of trusted root CAs —the so-called trust store (root store)—. Those roots are the starting point: anything they sign, directly or indirectly, inherits their trust.
That's why trusting a site doesn't require you to have seen it before; it's enough that its certificate descends from a root your system already knew the day you installed it.
You don't curate that store by hand: browser and operating-system vendors maintain it under strict criteria. If a CA misbehaves, they can eject it from the store, and with it every certificate it has signed stops being valid.
The chain of trust
CAs don't sign site certificates directly with their root —that key is too valuable to expose daily—. Instead they set up a chain:
- There's a root CA, whose certificate is already on your device and which you trust as a baseline. Its private key is kept with extreme care, offline.
- The root signs one or more intermediate certificates. These are the ones operating day to day, shielding the root from exposure.
- The intermediates sign the site's certificate —the "leaf"—, which is what the server presents when you connect.
- Your browser verifies the chain upward: from the site's certificate to the intermediate, from the intermediate to the root, until it lands on a trusted root.
If a signature doesn't check out at any link, the chain breaks, or the climb ends in a root your device doesn't know, the browser won't trust it. There are no shortcuts: either the chain reaches a trusted root, or it's worthless.
How the browser validates it
When you connect over HTTPS, the server hands you its certificate (and usually the intermediates). Your browser silently runs a checklist before showing the padlock:
- It checks the certificate hasn't expired and hasn't been revoked —a CA can invalidate a certificate ahead of time if, for example, its private key leaked—.
- It checks the certificate's domain matches the one you're visiting. A certificate for
bank.comisn't valid foranother-site.com. - It verifies the signature following the chain up to a trusted root, exactly as we saw above.
- If it all checks out, it shows the padlock and establishes the encrypted session. If something fails, it shows the "not secure" warning and stops you.
All of this happens during the handshake, before a single byte of the page loads. By the time you see the padlock, those four checks have already passed.
Common mistakes
"The padlock —or the valid certificate— means the company is legitimate or trustworthy." Not necessarily. A DV (domain validation) certificate, the most common one, only proves that whoever requested it controls the domain, not who the organization behind it is. A fraudulent site can hold a perfectly valid certificate for its own domain. The certificate proves domain control and enables encryption; it does not vouch for honesty.
Around that central confusion there are a few other common slips:
- Mistaking "valid certificate" for "trustworthy site". The padlock says "the connection is private and I'm talking to whoever controls this domain", not "these people are honest".
- Using self-signed certificates in production. A certificate that signs itself descends from no trusted root: the browser rejects it and trains users to click through warnings.
- Ignoring the expiration date. An expired certificate takes the site down for everyone, all at once. It's one of the most common —and most avoidable— causes of outages in production.
The banking angle
In banking, PKI isn't limited to consuming public certificates for customer-facing sites. Behind the scenes, institutions run their own internal PKI so services authenticate to each other before exchanging anything.
- mTLS (mutual TLS). On a public service, only the server presents a certificate; the client doesn't. In banking, between critical services they use mTLS: both ends present a certificate and validate each other. No one talks to anyone without proving identity.
- Controlled issuance, rotation and revocation. The internal PKI issues short-lived certificates, rotates them automatically, and can revoke them instantly if a service is compromised —without depending on an external public CA—.
- Pinning. For critical services they "pin" exactly which certificate or which CA is expected from the counterparty. If a different one shows up —even a technically valid one—, it's rejected. It's a direct defense against impersonation and against a compromised CA.
Trust on the web isn't magic: it's a chain of signatures someone has to issue, validate and renew on time. The padlock is the visible result of that chain working. In a bank, where each service proves itself to the next, that chain isn't left to chance —it's governed—.
