When you first deploy a custom application (like a MERN stack app) to a cloud server, dealing with domains, NGINX, and SSL certificates can feel like a black box. Your senior developer tells you to "just run Certbot," a few files magically appear, and suddenly your site has a secure padlock.
Let's demystify what is actually happening behind the scenes. By the end of this guide, you will understand how Namecheap, your server, Certbot, Let's Encrypt, and NGINX all fit together.
The big picture: the architecture
Before diving into how certificates are made, it helps to understand how traffic flows into your application server:
- The registrar (Namecheap). You buy your domain here. Namecheap acts as the land registry holding the deed to your domain name.
- The DNS A record. You point your domain's A record to your cloud server's public IP address. This tells the global internet where your server lives.
- The reverse proxy (NGINX). NGINX stands guard at the front door of your server on Port 80 (HTTP) and Port 443 (HTTPS).
- The backend app (Node.js). Your backend runs safely in the background on a local port (like 3000), completely unaware of the outside world, receiving clean traffic from NGINX.
User → DNS (A record) → Server IP
↓
NGINX :80 / :443
↓
Node.js :3000
Step-by-step: the Certbot and SSL lifecycle
Step 1: Proving you own the domain
When you SSH into your server, install Certbot, and run a command specifying your domain, Certbot does not immediately grab a certificate. First, it performs a strict security check.
Certbot checks the global internet DNS records to see if your domain's A record points to your current server's IP address. If it matches, Certbot proceeds. If it points to an old IP or a different server, the process fails instantly. This prevents malicious actors from getting certificates for domains they do not control.
Step 2: Downloading from Let's Encrypt
Once ownership is verified, Certbot talks to Let's Encrypt — a massive, non-profit Certificate Authority sponsored by tech giants like Google, AWS, and Mozilla.
Let's Encrypt issues a validation challenge, ensuring you control the server. Once passed, Certbot downloads the official SSL certificate files (fullchain.pem and privkey.pem) and saves them into a secure folder on your server's hard drive, usually under /etc/letsencrypt/.
Step 3: The handshake with the user
When a user types your URL into their browser, Certbot's job is already done — it goes to sleep until it's time to renew next month. Instead, NGINX takes over:
- The user visits your app over Port 443 (HTTPS).
- NGINX looks into the folder where Certbot saved those certificate files and hands them to the user's browser.
- The browser verifies that the certificate is valid, authentic, and issued by Let's Encrypt.
- The browser and NGINX mathematically negotiate a temporary session key.
Step 4: Encrypted data transmission
From that microsecond onward, every piece of data the user sends — passwords, clicks, form inputs — is locked with that encryption key. A hacker intercepting the traffic on the network will only see random mathematical gibberish.
NGINX receives the encrypted traffic, decrypts it using the secret key, and forwards a clean, unencrypted request internally to your Node.js backend on Port 3000.
Summary: who does what?
Component Role
--------- ----
Namecheap Holds your domain name and provides the DNS settings.
DNS A record Points your domain name to your cloud server's public IP address.
Let's Encrypt The non-profit authority that issues free, automated SSL certificates.
Certbot The tool you run on your server to prove domain ownership and
download the certificate.
NGINX The front-line security guard that holds the certificate, handles
encryption, and proxies traffic to your backend.
I write about the systems behind shipping AI features — RAG pipelines, evals, and the gap between demo and production — in my newsletter, AI Shipped. New issue every week.