Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.
In previous article we could able to setup basic nginx server and server simple html page.
Now let's setup https for our nginx server.
Requirements
Before we start setting up https we should do the following:
- Buy a domain name from any registrar.
- Set up dns records to point to our server ip.
- Setup Certificate for our domain name.
- Install nginx on our server.
- Set up nginx server to serve our website.
Buying Domain Name
We can buy domain name from any registrar like Namecheap, GoDaddy, etc.
It depends on which name it is and the charges will be around
Setting Up DNS Records
Once buy setup the dns records to point to our server ip.
Example:
For your server the ip address is [IP_ADDRESS].
And your domain name is [EMAIL_ADDRESS]
So, you need to set up a dns record to point to your server ip.
Setting up Certificate
Now let's setup certificate for our domain name.
example.com
so, we setup
sudo certbot --nginx -d `example.com` --email [EMAIL_ADDRESS] --agree-tos --no-eff-email
Here is simple workflow on how certificate is fetched and how
Key generation
The Certbot generates a private key and a CSR (Certificate Signing Request) entirely on your machine.
The private key is the core security guarantee.
HTTP-01 Challenge
Let's Encrypt needs to verify you actually control example.com. It sends Certbot a random token.
Certbot places it at:
/var/www/html/.well-known/acme-challenge/<random-token>
Nginx (already running on port 80) serves this file publicly.
Let's Encrypt fetches the token
LE makes a plain HTTP request to http://example.com/.well-known/acme-challenge/<token>.
If it gets the right response back, it's satisfied that you own the domain.
This is why DNS must be pointing to your server before you run Certbot — if the domain pointed elsewhere, LE would fetch the token from the wrong machine and the challenge would fail.
Certificate issued & saved
LE signs and returns your certificate.
Certbot saves four files to /etc/letsencrypt/live/example.com/:
| File | What it is |
|---|---|
fullchain.pem |
Your cert + intermediate CA chain (this is what Nginx uses) |
privkey.pem |
Your private key (Nginx uses this too) |
cert.pem |
Just your cert alone |
chain.pem |
Just the CA chain alone |
Nginx config is rewritten
Certbot patches your server block to add the listen 443 ssl lines and the cert paths, and adds a new server { listen 80; } block that redirects all HTTP traffic to HTTPS.
Then it reloads Nginx for you.
Setting up with nginx
Assuming your application running in local host 8090. and you are setting up https for your domain name example.com.
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# All requests — public, no auth
location / {
proxy_pass http://localhost:8090;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
Add to symlink to sites enabled
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
Restarting nginx
sudo nginx -t && sudo systemctl reload nginx
Conclusion
We could get https for our domain name example.com.
Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc


Top comments (0)