HTTPS, SSL and TLS: Certificates, Let’s Encrypt, ACM

Concept — postcard vs sealed box

HTTP (HyperText Transfer Protocol) is the set of rules that browsers and servers use to talk. It sends everything as plain readable text. HTTPS is HTTP made safe.

• HTTP is like a message written on a postcard. Every postman and every sorting office that touches it can read it. Nothing needs to be opened.
• HTTPS is the same message inside a locked box. Only the receiver has the key. People can still see the box travelling and who it is addressed to. But they cannot read what is inside.

The technology that does the locking is TLS (Transport Layer Security). You will often hear “SSL certificate”. SSL was the older version of the same idea. It is now obsolete, but the name stuck. When someone says SSL today, they almost always mean TLS.

What actually leaks without HTTPS

Say your app is live on EC2 with no HTTPS, and a customer logs in from a café WiFi. This is what travels across that network:

POST /api/login HTTP/1.1
Host: yourapp.com
Content-Type: application/json

{"email":"user@example.com","password":"Acme@2026"}

With HTTPS enabled, the exact same login sends this instead:

17 03 03 00 45 8f a3 d9 e2 b1 7c 4f 6a 2d 91 ...

These are meaningless bytes. It is the same request and the same data, but nobody can read it.

HTTPS does three jobs, not one

Most people only know the first one. All three matter.

Key terms explained

The chain of trust

Your browser has never heard of yourapp.com. So why does it trust it?

Certificates work the same way. Every browser and operating system comes with a built-in list of Root Certificate Authorities (the top-level CAs) that it trusts. The list has more than 100 root certificates. A root CA signs an intermediate certificate. The intermediate signs yours. This is the chain.

If any link in the chain is missing, expired, or signed by someone the browser does not know, you see the red warning page.

The handshake, step by step

The handshake is the short opening talk between browser and server. It takes milliseconds. It happens once per connection, before your page starts to load.

1. Browser says hello

   It connects and says “I want to use TLS. Here are the encryption methods I support.”

2. Server sends its certificate

   It also sends the intermediate certificates (the chain), and picks one of the encryption methods the browser offered.

3. Browser verifies the certificate

   It makes three checks. Is it signed by a trusted CA? Is today's date inside its valid dates? Does the domain name on it match the site I typed?

4. Both sides agree a shared key

   A key exchange is a way for two sides to create the same secret key without sending it over the network. Both sides now have a shared secret key. Nobody who watched the talk can work it out.

5. Everything after this is encrypted

   All page content, form data and API calls now travel inside the encrypted connection (the “tunnel”).

Two ways to get a free certificate

Real example — HTTPS on your EC2 server

Certbot is a free tool that gets Let's Encrypt certificates and sets them up for you. Install it with its Nginx plugin. Then ask for a certificate that covers both the bare name and the www name:

Certbot also sets up a timer that renews the certificate before its 90 days end. You do not need to touch it. But test it once with sudo certbot renew --dry-run, so you are not surprised in three months. (Let's Encrypt plans shorter lifetimes in the future. The timer handles that too.)

The Nginx config afterward

server {
    listen 443 ssl;
    ssl_certificate     /etc/letsencrypt/live/yourapp.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourapp.com/privkey.pem;
    # ...your existing location / { proxy_pass ... } stays as it was
}

server {
    listen 80;                                  # plain HTTP
    return 301 https://$host$request_uri;       # push everyone to HTTPS
}

Look at fullchain.pem. This file holds your certificate plus the intermediate certificate. That is the chain from the diagram above.

Common errors you will actually hit

Mixed content is the most common problem when you first move to HTTPS. The page loads, but some images quietly disappear, and the padlock shows a warning instead of a clean lock.

Verifying it yourself

In the browser, click the padlock icon next to the address. It shows the issuer, the valid dates and the full certificate chain. It is the same information in an easier form.

What HTTPS does not do

Cost

Let's Encrypt certificates are free. Public ACM certificates are free too, when used with AWS services such as a load balancer. The only indirect cost is the Load Balancer that ACM needs. Lesson 12 prices it properly.

Practice task before Lesson 5

You do not have a server yet, so today you look at certificates that already exist. Every command only reads data and works from your laptop.

curl -I http://github.com      # expect 301 and a Location: https://... header

Then open https://github.com and click the padlock: find the issuer, the expiry date and the chain. Finally visit https://expired.badssl.com and https://wrong.host.badssl.com and read the exact error each one shows.

Then answer these in your own words:

1. Look at the three checks in handshake step 3. Which one did wrong.host.badssl.com fail? Which one did expired.badssl.com fail?
2. Why can you not use a free ACM certificate on your first EC2 server? What will you use instead?
3. Certbot says “challenge failed”. Name the two things from Lessons 2 and 3 that you check before you run Certbot again.
4. Your site has a perfect padlock, but a customer's data was stolen from the database. Did HTTPS fail? Why or why not?

Conclusion

HTTPS is HTTP inside a locked box. TLS does the locking. A certificate proves whose box it is. A chain of trust back to a Root CA is why your browser believes that proof, even though it has never met your server.

• Three jobs: encryption (nobody can read it), authentication (it really is yourapp.com) and integrity (nobody changed it). Certificates are for the second job.
• The handshake takes milliseconds. Step 3 (trusted CA, valid dates, matching name) is where every red warning page comes from.
• Two free sources: Let's Encrypt (Certbot) for a plain EC2 + Nginx server in Lesson 7, and ACM from Lesson 12, once an ALB or CloudFront ends TLS for you.
• Before Certbot: DNS must point to the server and port 80 must be open. After Certbot: protect privkey.pem like the .env file from Lesson 1.
• Not a full protection: HTTPS protects data in transit only. The database and the code are the topic of Lesson 18.

Lessons 2, 3 and 4 together show the whole path from a typed domain name to an encrypted talk with your app. Next we go back into the AWS account and set up identity properly.

End of Lesson 4. Next: Lesson 5 — AWS Account and IAM.

Before Lesson 5, read: The Pieces You Keep Hearing About → — Nginx, PM2, load balancers, RDS, VPC and every other name that Lessons 0–4 mention but do not yet explain, each with a flow diagram and a short “how”.