What Is an SSL Certificate, and Why Do You Need One? Certificates and the Trust Chain of a CA

Click the padlock on the left of the address bar and you see something like “this connection is secure” or “the certificate is valid.” But who creates this thing called a certificate, and on what grounds does it say “secure”? After all, the person who built the site could just declare “I’m safe” about their own site — so why isn’t that enough?

In this post I’ll lay out, without code, what an SSL certificate is, why you need one, and who vouches for it. If you’re curious about the principle of locking communication with a cipher itself, reading What the Padlock in Your Address Bar Protects first will help.

A certificate is an ID card proving “this site is the real one” #

HTTPS does two things. One is to lock the content you exchange with a cipher; the other is to verify that the party you’ve connected to really is that site. The certificate is the second of these — the paper that proves identity.

For a person, it’s like an ID card. An ID card means something not because you made the paper yourself, but because a trustworthy institution issued it. A certificate is the same. A site claiming on its own “I am schoolofweb.net” isn’t enough; only when a trustworthy issuing institution vouches for that claim does the browser accept it.

Why isn’t encryption alone enough? #

There’s a common misunderstanding here: the idea that “if the communication is encrypted, isn’t it safe?” But encryption only prevents others from reading what’s exchanged; it doesn’t guarantee that the party you’re talking to right now is genuine.

Suppose a fake site puts up a screen that looks exactly like the real one and locks the communication with a cipher. The content is certainly protected by encryption, but the one sitting on the other side of that cipher is an attacker. With encryption alone, you can end up “safely handing your password to a fake.” That’s why, alongside encryption, you absolutely need a certificate that vouches for the party being genuine.

Who vouches for it: the certificate authority (CA) #

The institution that provides this assurance is called a certificate authority, or CA. A CA verifies that the person requesting the certificate really is the owner of that domain, then issues a certificate signed to say “this domain belongs to this entity.”

So why can we trust a CA we’ve never seen before? The secret is in the browser and the operating system. Browsers and operating systems carry a list of CAs that have been verified in advance as trustworthy. If a certificate is signed by a CA on that list, the browser accepts it without separate checks. That’s why we don’t have to verify each CA ourselves every time.

Trust runs as a chain #

A certificate usually works not as a single sheet but as several linked together like a chain. At the top is the most important root certificate, below it an intermediate certificate, and at the bottom our site’s certificate.

• Root certificate: the starting point of trust, planted in browsers and operating systems in advance. It’s so important that it’s normally kept deep in storage and not used directly.
• Intermediate certificate: a certificate the root signed to say “you can trust this intermediate authority.” Actual issuance happens at this intermediate stage.
• Site certificate: the certificate our site actually uses, signed by the intermediate to say “this domain is genuine.”

The browser starts from the site certificate, passes through the intermediate, and works its way up to the root, checking that the chain reaches a pre-trusted root without breaking. If the chain breaks anywhere, the browser can’t trust the certificate. That’s why “the intermediate certificate is missing” often turns into an incident in practice.

Certificates have a validity period, too #

Just as an ID card has a renewal deadline, a certificate has a validity period. Certificates issued these days tend to be short-lived, and you have to renew with a new one before the term ends.

Miss the renewal and let the certificate expire, and the browser decides it can no longer vouch for the identity and throws a loud “not secure” warning. The site itself is alive, but visitors turn away at the red warning screen. That’s why the standard now is to renew certificates automatically rather than having a person tend to them. But when that automatic renewal goes off track, the same problem appears all the same.

What gets easier once you know this #

• You read warning screens calmly. When “not secure” appears, instead of blindly ignoring it or panicking, you can figure out whether the cause is an expired certificate or a name mismatch.
• You handle renewals before they become incidents. Knowing a certificate has a validity period, you can check in advance that automatic renewal is running.
• You can talk with the people in charge. You can follow remarks like “the intermediate certificate is missing” or “we need a wildcard certificate.”

Wrapping up #

Today we looked at what a certificate is, why you need one, and who vouches for it. A certificate is a site’s ID card, a certificate authority (CA) vouches for that identity, and the trust runs as a chain from root through intermediate to site certificate. If encryption is the job of keeping things from being peeked at, the certificate is the job of vouching that the other party is genuine.

If that’s the concept, then how you actually obtain a certificate, install it on a server or in the cloud, and renew it automatically is covered hands-on in HTTPS Certificates in Practice. And since a certificate only means something once the name — the domain — exists first, if you haven’t read What Is a Domain, and Why Do You Need One? yet, it’s worth reading alongside.