SSL Certificates in Practice: Getting HTTPS Working on a Real Deployment

There’s a moment in almost every deployment where the app works perfectly over plain HTTP, the team is happy, and then someone opens the site in a browser and sees a big red “Not secure” warning. Suddenly the question stops being theoretical. You don’t just need to know that HTTPS uses certificates — you need a real certificate, installed on a real server, trusted by real browsers, and you need it to keep working next month without anyone babysitting it.

This article is about that practical side. We’ll assume you already grasp the idea that HTTPS encrypts traffic — if the underlying handshake is still fuzzy, the conceptual companion to this piece is SSL, TLS, and HTTPS. Here, the goal is different: how a certificate actually gets onto a box, what files you’re dealing with, how renewal works, and the small mistakes that turn a five-minute task into a stressful afternoon.

What an SSL certificate actually is

Strip away the jargon and a certificate is a small file that does two jobs at once. First, it carries a public key that lets a browser set up encryption with your server. Second, it carries a signed statement that says, in effect, “a trusted authority checked that whoever controls this certificate also controls the domain example.com.” That second part is the whole point. Encryption alone is easy; proving you are who you say you are is the hard problem a certificate solves.

The signature comes from a Certificate Authority (CA) — an organization that browsers and operating systems already trust by default. When a visitor connects, their browser checks the chain: your certificate is signed by the CA, the CA is on the browser’s built-in trust list, the domain matches, and the date hasn’t expired. If every link holds, you get the padlock. If any link breaks, the browser throws a warning and most users leave.

The cast of files you’ll meet

When you provision a certificate, you don’t get a single magic file — you get a small set, and knowing what each one is saves a lot of confusion. Here’s the typical lineup:

• Private key — a secret file (often privkey.pem or something.key) generated on your server. This never leaves the machine and is never shared. If it leaks, your certificate is compromised. Everything else can be public; this one cannot.
• Certificate — the signed public file (cert.pem or something.crt) that proves your domain. This is what the CA hands back to you.
• Chain / intermediate certificate — one or more files that connect your certificate up to the CA’s root. Browsers need this to verify the trust path. Forgetting it is the single most common “works on my machine, fails for users” bug.
• Fullchain — many tools bundle your certificate plus the chain into one convenient file (fullchain.pem) so the server can serve everything in the right order.

   how the trust chain links together

   Root CA          (trusted by the browser already)
      │  signs
      ▼
   Intermediate CA  (the "chain" file)
      │  signs
      ▼
   Your certificate (cert.pem — your domain)
      │  pairs with
      ▼
   Private key      (privkey.pem — secret, stays on server)

The browser walks up that chain. It starts with your certificate, follows the chain to a root it trusts, and only then decides you’re legitimate. Serve the chain incorrectly and some browsers (often older ones or non-browser clients like mobile apps) will reject the connection even though your certificate is perfectly valid.

How a certificate gets issued

Behind every certificate is a small ritual called the issuance flow. Understanding it demystifies why the automated tools do what they do.

1. Generate a key pair. Your server creates a private key (kept secret) and a matching public key.
2. Create a CSR. You bundle the public key plus details like your domain name into a Certificate Signing Request and send it to the CA. The CSR never contains your private key.
3. Prove you control the domain. The CA challenges you to demonstrate ownership — usually by placing a specific file at a path on your site, or adding a specific DNS record. This is domain validation, and it’s why you can’t just request a certificate for a domain you don’t own.
4. Receive the signed certificate. Once validation passes, the CA signs your certificate and sends it back, along with the chain.
5. Install it. You point your server software at the certificate, the chain, and the private key, and reload. Traffic is now encrypted and trusted.

For years this was a manual, sometimes paid, often annoying process. Then the ACME protocol standardized all of it, and free CAs made certificates automatic and zero-cost. Today a single command on your server can run the entire flow — generate the key, submit the CSR, answer the validation challenge, fetch the certificate, and install it — in a few seconds.

Certificates expire — and that’s by design

Here’s the fact that catches most people off guard: certificates are short-lived on purpose. A typical free certificate is valid for around 90 days, and the industry has been steadily pushing that window shorter, not longer. It feels inconvenient, but it’s a deliberate security trade-off. If a private key is ever quietly compromised, a short lifetime limits how long the damage can last. A certificate that’s valid for years is a long-lived liability.

The catch is obvious: a certificate that expires every 90 days is a recurring chore, and a forgotten renewal means your whole site goes dark behind a scary browser warning. The answer is automated renewal. The same tooling that issues certificates can be scheduled to check them regularly and renew before they expire — typically with a window of several weeks to spare, so a single failed attempt isn’t a catastrophe.

# the shape of a typical automated-renewal check
# (run on a schedule, e.g. twice a day)

renew-certificates --check
# → certificate for example.com expires in 27 days → renewing...
# → certificate for example.com expires in 81 days → nothing to do

The key mental model: issuance is a one-time event, renewal is a forever process. A deployment isn’t “done” with HTTPS the moment the padlock appears. It’s done when renewal is automated and something tells you if that automation ever fails.

After install: making HTTPS actually stick

Getting a valid certificate served is the milestone, but a production-grade setup usually adds a few finishing touches so visitors land on the secure version every time.

• Redirect HTTP to HTTPS. With a certificate in place you can still be reached over plain http://. A redirect rule sends every such request to the https:// version, so no one accidentally browses unencrypted.
• HSTS. A response header (HTTP Strict Transport Security) tells browsers to only ever use HTTPS for your domain going forward, even if a user types http:// or clicks an old link. It closes the brief window before the redirect kicks in. Turn it on only once you’re confident HTTPS is solid, because it’s sticky by design.
• Cover every name. A certificate is issued for specific names. If you serve both example.com and www.example.com, both need to be on the certificate, or one of them will throw a warning. Listing the names you actually use is a quick check that saves a confusing bug report later.
• Mind the renewal’s needs. HTTP validation needs a specific path reachable on port 80; DNS validation needs API access to your DNS. Whatever method renewal uses, make sure nothing in your deployment (a firewall rule, a blanket redirect, a locked-down DNS) quietly breaks it down the line.

If you’re deploying behind a load balancer or a managed platform, the certificate often lives at that edge layer rather than on each individual server — the platform terminates TLS for you. The concepts are identical; only the place the certificate sits changes. This is a natural extension of the ideas in how deployment works, where the request first hits an edge before reaching your application.

Why this matters beyond the padlock

It’s tempting to treat HTTPS as a checkbox — get the padlock, move on. But the certificate is doing real, ongoing work every second your site is live. It’s the reason a visitor’s password isn’t readable by anyone on the same coffee-shop Wi-Fi, the reason a payment form can be trusted, and the reason browsers and search engines treat your site as legitimate rather than flagging it. Modern browsers increasingly refuse to load insecure content, and many web features simply won’t run without HTTPS at all.

So the practical skill here isn’t a one-off command you memorize. It’s the mindset: a certificate is a credential with an expiry date, tied to a domain, backed by a chain of trust, and kept alive by automation you can verify. Get that loop right once, and HTTPS stops being a fire drill and becomes the quiet, boring infrastructure it’s supposed to be.

Wrapping up

The whole picture, condensed:

• An SSL/TLS certificate is a signed file that both enables encryption (via its public key) and proves you control a domain (via a CA’s signature).
• You’ll handle a small set of files — a secret private key, the certificate, and the chain that links it to a trusted root. Serving the chain wrong is the classic silent failure.
• Issuance follows a fixed flow: generate a key, submit a CSR, pass domain validation (HTTP or DNS), receive the signed certificate, install it. The ACME protocol made this free and automatic.
• Certificates are short-lived on purpose. Automated renewal plus expiry monitoring is what keeps a site secure long-term — expired certificates cause far more outages than attacks do.
• Finish the job with an HTTP→HTTPS redirect, optionally HSTS, and by making sure every domain name you use is covered.

Next, it’s worth following the request one step further out — how a domain actually gets pointed at the right environment so that the certificate, the DNS, and the server all line up on the same address your visitors type.