CodingNic
Sign In Book Session

Reverse Proxies & HTTPS

HTTPS and Certificates

Reverse Proxies & HTTPS 15 min read

HTTPS and Certificates

Objectives

By the end of this lesson, you should be able to:

  • Explain what a TLS certificate actually proves, and what it encrypts
  • Explain what “HTTPS termination” means, and where it typically happens
  • Get a free, automatically renewing certificate with Let’s Encrypt

💡 Why this matters: Every request in this course has been plain HTTP, unencrypted, readable by anything between a client and the server. Real applications handling real credentials, exactly what Course 3 built, need every request encrypted, this lesson covers how that actually happens.

⚠️ A note on verification: obtaining a real certificate requires a real, publicly resolvable domain, which this course’s sandboxed tooling doesn’t have. The behavior below reflects Let’s Encrypt’s and Certbot’s stable, current, documented process. Follow these steps yourself, against a real domain, to obtain a real certificate.

What a Certificate Actually Proves

A TLS certificate does two things: it proves a server is who it claims to be (issued by a trusted certificate authority, verifying whoever requested it actually controls the domain), and it enables encryption for the connection, so anything sent, a password during login (Course 3), a JWT in an Authorization header, can’t be read by anything intercepting the traffic in between. Without it, a login request over plain HTTP sends a password in cleartext, over any network the request happens to cross.

Where HTTPS Termination Happens

“HTTPS termination” means decrypting an incoming HTTPS connection, this almost always happens at the reverse proxy, Nginx (Lesson 2), or a platform’s own load balancer (Module 5), not inside the Node.js application itself. Traffic between a client and the proxy is encrypted, traffic between the proxy and the application, often on the same private network or even the same machine, is typically plain HTTP, this is a deliberate, standard trade-off, encryption is expensive to set up correctly everywhere, terminating it once, at the edge, is simpler and, for most deployments, secure enough, since the internal network isn’t exposed the way the public internet is.

Let’s Encrypt and Certbot

Let’s Encrypt is a free, automated certificate authority, Certbot is the most common tool for actually requesting and installing a certificate from it:

bash
sudo certbot --nginx -d api.example.com

Certbot verifies domain ownership (typically by briefly serving a specific file Let’s Encrypt checks for, or a DNS record), obtains a certificate, and, with the --nginx flag, updates the Nginx configuration from Lesson 2 automatically, adding the listen 443 ssl block and pointing it at the new certificate files.

Automatic Renewal

Let’s Encrypt certificates expire after 90 days, deliberately short, to limit the damage of a certificate that’s compromised or forgotten, Certbot installs a scheduled renewal job automatically, running periodically, renewing well before expiration, without anyone needing to remember to do it manually, an expired certificate on a live production API would mean every client refusing the connection entirely, this automation is what prevents that from ever becoming a real incident.

What Nginx Looks Like with HTTPS

text
server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header X-Forwarded-Proto https;
    }
}

server {
    listen 80;
    server_name api.example.com;
    return 301 https://$host$request_uri;
}

Two server blocks, one handling HTTPS on port 443, with the certificate files Certbot obtained, the other redirecting any remaining plain HTTP traffic (port 80) to HTTPS instead, X-Forwarded-Proto https tells the backend application the original request was encrypted, even though the connection between the proxy and the application itself typically isn’t.

Try It

  1. Explain, in your own words, what a TLS certificate proves, and what would go wrong for a user if a fraudulent certificate could be issued for a domain someone doesn’t actually control.
  2. If you have access to a real domain, run certbot --nginx against it, and confirm the resulting configuration matches the pattern above.
  3. Explain, in one or two sentences, why HTTPS termination usually happens at the proxy, not inside the Node.js application itself.
  4. Explain why Let’s Encrypt certificates expiring every 90 days, with automatic renewal, is safer than a certificate valid for several years with no renewal process at all.

Recap

  • A TLS certificate proves a server’s identity and enables encryption, protecting credentials and tokens from being readable in transit.
  • HTTPS termination typically happens at the reverse proxy, Nginx or a platform’s load balancer, not inside the application itself.
  • Let’s Encrypt provides free, automatically renewing certificates, Certbot handles both obtaining one and configuring Nginx to use it.

This is the final lesson of this module before exercises. Next lesson: exercises, building a complete reverse proxy setup, path routing, load balancing, and HTTPS, together.