KAHIBARO
Discord Login Register ☰
☰

22.9. Let's Encrypt

Table of Contents

Why Let's Encrypt Matters

When you put a backend application on the internet, you must protect traffic with HTTPS. Traditionally, HTTPS certificates were:

Let's Encrypt solves these problems by providing free, automated, and trusted TLS certificates. It has become the standard way to secure small and medium projects, side projects, and many production systems.

In this chapter you will learn what Let's Encrypt is, how it works, and how to use it with a typical Nginx or reverse proxy setup.

Key idea: Let's Encrypt gives you free, trusted TLS certificates, but you remain responsible for:

  • Proving control of your domain.
  • Configuring your web server correctly.
  • Automating renewals and reloads.

What Let's Encrypt Is

Let's Encrypt is a Certificate Authority (CA) run by the Internet Security Research Group (ISRG). A CA is an organization that issues digital certificates that browsers trust.

Important points about Let's Encrypt:

How Let's Encrypt Proves You Own a Domain

To get a certificate, Let's Encrypt must be sure that you control the domain that you request a certificate for.

There are several challenge types. The two most relevant for backend developers are:

HTTP-01 Challenge

The most common challenge when using web servers such as Nginx or Apache.

Workflow:

  1. Your ACME client (for example Certbot) contacts Let's Encrypt and says:
    • "I want a certificate for example.com."
  2. Let's Encrypt replies:
    • "Show me a special file at
      http://example.com/.well-known/acme-challenge/<token>
      with a specific content."
  3. The ACME client:
    • Places that file or response on your web server.
    • Configures a route for /.well-known/acme-challenge/* if needed.
  4. Let's Encrypt makes an HTTP request to that URL.
    • If it receives the expected content, it assumes:
      • You control the server that responds for example.com.
    • Then it issues the certificate.

Conditions for HTTP-01:

DNS-01 Challenge

Used when HTTP is not possible or when you want wildcard certificates like *.example.com.

Workflow:

  1. ACME client asks for a certificate for example.com or *.example.com.
  2. Let's Encrypt says:
    • "Create a TXT record in DNS for _acme-challenge.example.com with this token."
  3. You or your automation:
    • Create that DNS TXT record.
  4. Let's Encrypt checks DNS:
    • If the token matches, it issues the certificate.

Conditions for DNS-01:

Comparison table:

FeatureHTTP-01DNS-01
Used forSingle hostnamesSingle hostnames and wildcards
Needs port 80YesNo
Requires DNS changeNoYes (TXT record)
Automation difficultyUsually easy with web serverHarder without DNS provider API
Common useTypical web apps and APIsMulti-subdomain setups, complex routing

The ACME Protocol in Simple Terms

ACME is the protocol that tools like Certbot use to talk to Let's Encrypt.

The general ACME flow:

  1. Create an account key on your server.
  2. Register this account with Let's Encrypt.
  3. Request authorization for one or more domains.
  4. Solve challenges (HTTP-01 or DNS-01).
  5. Request a certificate once challenges pass.
  6. Retrieve the certificate, and optionally a chain or fullchain file.

You rarely need to implement ACME yourself. Instead, you pick a client:

Important: Do not try to "manually download" certificates through a web UI or email when using Let's Encrypt. It is meant to be used through an ACME client and automated.

Certificates from Let's Encrypt: What You Get

A typical Let's Encrypt issuance gives you:

Common file layout with Certbot:

FileDescription
privkey.pemYour private key, must be kept secret
cert.pemDomain certificate
chain.pemCA intermediate certificates
fullchain.pemcert.pem + chain.pem combined

Never share privkey.pem. If it leaks, someone can pretend to be your site.

Using Let's Encrypt with Nginx

Most backend setups use Nginx as a reverse proxy in front of an application server.

A common minimal Nginx HTTPS configuration with Let's Encrypt looks like this:

nginx 
server {
    listen 80;
    server_name example.com;
    # Redirect all HTTP to HTTPS
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Important details:

When you configure Nginx, ensure the paths to the certificate and key match where your ACME client saves them.

Using Certbot with Nginx: A Typical Flow

On a Linux server with Nginx, a common process is:

  1. Install Certbot and the Nginx plugin
    Exact commands depend on your Linux distribution. For example on Ubuntu:
bash 
   sudo apt update
   sudo apt install certbot python3-certbot-nginx
  1. Ensure DNS points to your server
    • For example.com, set an A record to your server IP.
    • Verify you can reach http://example.com from the internet.
  2. Obtain and install a certificate

You can let Certbot edit Nginx configuration automatically:

bash 
   sudo certbot --nginx -d example.com

Certbot will:

Or you can only obtain the certificate, and edit Nginx manually:

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

Then you configure ssl_certificate and ssl_certificate_key in Nginx.

  1. Reload Nginx

After adjusting configuration:

bash 
   sudo nginx -t      # Test config
   sudo systemctl reload nginx
  1. Automate renewal

Certbot often sets up a cron job or systemd timer automatically.

You can test renewal with:

bash 
   sudo certbot renew --dry-run

When certificates are renewed, Nginx must read the new files. Usually a reload automatically happens, or you can hook into the --deploy-hook option.

Rule: Always test a Let's Encrypt setup with a staging environment if you will try many times. Use Certbot's --staging flag to avoid rate limits during experiments.

Renewal and Short Certificate Lifetimes

Let's Encrypt certificates usually last 90 days. This is not a problem if you configure automation correctly.

With Certbot:

Typical renewal command:

bash 
sudo certbot renew

You do not usually run this manually. It runs periodically and renews certificates that are near expiration.

You can add hooks, for example:

bash 
sudo certbot renew --post-hook "systemctl reload nginx"

This reloads Nginx every time a certificate is renewed.

If you use DNS-01 with some ACME client, you must ensure your DNS automation still works at renewal time.

Rate Limits and Staging Environment

Let's Encrypt is a shared, public service, so it enforces rate limits. You must respect these or your domain will be temporarily blocked from obtaining certificates.

Typical rate limits (subject to change):

To experiment safely:

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

You get test certificates that are not trusted by browsers, but you can test:

When you are sure everything works, remove --staging to obtain real certificates.

Important rule: When testing automation or complicated setups, always start with Let's Encrypt staging, to avoid hitting rate limits on the production servers.

Common Problems and How to Avoid Them

Port 80 Blocked or Misconfigured

Symptoms:

Causes:

Solution:

nginx 
  server {
      listen 80;
      server_name example.com;
      location /.well-known/acme-challenge/ {
          root /var/www/letsencrypt;
      }
  }

Or let Certbot configure it automatically with --nginx.

Wrong DNS Configuration

Symptoms:

Cause:

Solution:

Forgetting to Reload Nginx

Renewal might succeed, but Nginx will continue using the old certificate until it is reloaded.

Solution:

bash 
  sudo certbot renew --post-hook "systemctl reload nginx"

Using HTTP-01 with Multiple Load Balancers

If you have multiple reverse proxies or load balancers, HTTP-01 might fail if:

Solution options:

Let's Encrypt in Containerized Setups

In Docker based environments with Nginx or Traefik as reverse proxies, Let's Encrypt is still commonly used.

Typical patterns:

Example Nginx + Certbot volume sharing:

yaml 
services:
  nginx:
    image: nginx:alpine
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - certs:/etc/letsencrypt
    ports:
      - "80:80"
      - "443:443"
  certbot:
    image: certbot/certbot
    volumes:
      - certs:/etc/letsencrypt
      - ./html:/var/www/certbot
    command: certonly --webroot -w /var/www/certbot -d example.com
volumes:
  certs:

You still must:

Security Considerations

Using Let's Encrypt does not automatically make your site secure. It only encrypts traffic and verifies domain control.

Security notes:

Core rule: Let's Encrypt handles identity and encryption for your domain, but you must still handle application security, server hardening, and secret protection yourself.

Putting It All Together in a Backend Context

In a typical backend deployment with a FastAPI app and Nginx:

  1. Develop your app and run it with Uvicorn or Gunicorn on port 8000.
  2. Install Nginx as a reverse proxy and configure it to:
    • Accept HTTP on port 80.
    • Proxy requests to localhost:8000.
  3. Use Certbot / ACME client to obtain a Let's Encrypt certificate for your domain.
  4. Configure Nginx HTTPS server block with:
    • ssl_certificate pointing to fullchain.pem.
    • ssl_certificate_key pointing to privkey.pem.
  5. Set up automatic renewal and Nginx reload.
  6. Redirect HTTP to HTTPS so all client traffic is protected.

Once configured, certificates will renew in the background. Your backend will always be served over HTTPS with a certificate that browsers trust, without any ongoing manual work.

Views: 7

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3086 / 24h
Impressum / Imprint
Datenschutz / Data Policy