Let's Encrypt for Nginx: Complete Setup, Redirects, and Renewal Checklist

Overview

This article gives you a maintainable way to handle Let’s Encrypt for Nginx rather than a one-time command sequence that is hard to trust later. The goal is simple: issue a certificate, serve it correctly, redirect HTTP to HTTPS without breaking validation, and make renewal predictable.

In most small and mid-sized deployments, the working stack looks like this:

• A domain or subdomain already points to your server with an A or AAAA record.
• Nginx is installed and serving the intended site.
• A Let’s Encrypt client such as Certbot can write challenge files or modify Nginx temporarily.
• Ports 80 and 443 are reachable from the public internet.
• You have shell access with permission to edit Nginx and reload services.

If any of those assumptions are untrue, fix them before requesting a certificate. SSL problems often start as DNS or virtual host problems, not certificate problems.

For most readers, there are two sensible paths:

1. Use Certbot with the Nginx plugin if you want automation and your Nginx layout is conventional.
2. Use webroot mode if you prefer explicit control over Nginx configuration and challenge handling.

If your environment uses containers, immutable images, a CDN proxy, or DNS-based validation, you may need a different flow. For DNS automation and wildcard setups, see Let’s Encrypt DNS-01 Automation by Provider and Let’s Encrypt Wildcard Certificates.

A minimal Nginx HTTP server block for pre-issuance testing often looks like this:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.html index.htm index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

Before touching TLS, confirm that:

• curl -I http://example.com returns a response from your server.
• nginx -t passes.
• Your server block is the one actually handling the requested hostname.

Checklist by scenario

Use the scenario closest to your environment. Each list is meant to be followed in order.

Scenario 1: New single-site Nginx server using Certbot’s Nginx integration

This is the fastest path when you have a standard VPS or cloud server and a normal Nginx site definition.

1. Point DNS first. Set the domain’s A record to the server’s IPv4 address and, if used, AAAA to the IPv6 address.
2. Wait for the domain to resolve correctly. Test with dig, host, or your preferred DNS checker.
3. Create and test a working Nginx server block on port 80. The site should load before SSL is introduced.
4. Open firewall rules for 80 and 443. Certificate issuance and web traffic both depend on them.
5. Install Certbot and the Nginx integration package using your distribution’s standard method.
6. Run a dry evaluation of your Nginx config. Make sure duplicate server names, syntax errors, and broken includes are fixed.
7. Request the certificate. A typical command is:

sudo certbot --nginx -d example.com -d www.example.com

8. Choose redirect behavior carefully. If prompted, enable HTTP to HTTPS redirect unless you have a reason to keep plain HTTP reachable.
9. Review the generated Nginx changes. Do not assume automated edits match your preferred layout.
10. Test the final configuration. Confirm both the certificate and the redirect behavior with curl and a browser.

A typical resulting HTTPS server block may include lines like these:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

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

    root /var/www/example.com/public;
    index index.html index.htm index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

And the HTTP redirect block may look like this:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    return 301 https://$host$request_uri;
}

Scenario 2: Existing Nginx site where you want manual control with webroot

Use this when your Nginx configuration is customized and you do not want a tool to rewrite it.

1. Create or confirm the site root. Example: /var/www/example.com/public.
2. Add an ACME challenge location to the HTTP server block.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;

    location ^~ /.well-known/acme-challenge/ {
        default_type "text/plain";
        allow all;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

3. Reload Nginx and test the challenge path manually. Place a test file under .well-known/acme-challenge/ and fetch it over HTTP.
4. Request the certificate in webroot mode.

sudo certbot certonly --webroot -w /var/www/example.com/public -d example.com -d www.example.com

5. Add SSL directives to the HTTPS server block.
6. Add a clean HTTP-to-HTTPS redirect after issuance succeeds.
7. Run nginx -t and reload.

This approach is often easier to maintain because challenge handling is explicit and the certificate request does not depend on Nginx parsing heuristics.

Scenario 3: HTTPS redirect on Nginx without breaking renewal

Many admins worry that a forced redirect will interfere with Let’s Encrypt. In a standard setup, it does not have to. The safe pattern is either to let Certbot manage the challenge automatically or to make sure the challenge location is reachable before the redirect catches everything else.

A manual HTTP server block that preserves challenge access can look like this:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;

    location ^~ /.well-known/acme-challenge/ {
        default_type "text/plain";
        allow all;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

This pattern is useful if you are handling HTTPS redirect Nginx rules manually and want predictable renewal behavior. If HTTP-01 validation still fails, work through How to Fix Let’s Encrypt HTTP-01 Challenge Failures.

Scenario 4: Multi-site Nginx server with several domains

Shared Nginx hosts and small VPS deployments often serve multiple domains. The main risks are default server confusion and reusing the wrong certificate path.

1. Verify each domain resolves to the correct server.
2. Make sure every hostname has its own matching server_name.
3. Issue certificates per site or per logical hostname group.
4. Avoid copying certificate paths between unrelated server blocks.
5. Check that the intended site answers over both 80 and 443.

If you have many SAN names on one certificate, keep an eye on operational complexity. A certificate tied to too many hostnames can make renewals and migrations harder to reason about.

Scenario 5: Reverse proxy, CDN, or nonstandard topology

If Nginx sits behind another layer, plain HTTP validation may fail even when the local config looks correct.

• If a CDN proxy is enabled, confirm whether it forwards the ACME challenge cleanly.
• If another load balancer terminates port 80, make sure challenge requests reach the backend.
• If port 80 cannot be exposed, DNS-01 validation may be the better fit.
• If you need wildcard certificates, plan for DNS-01 from the start.

In these environments, it is worth comparing clients and automation models rather than defaulting to Certbot alone. See Best Let’s Encrypt Clients Compared.

Scenario 6: Renewal checklist for stable operations

Issuance is only half the job. Renewal is where neglected setups fail.

1. Confirm the renewal mechanism exists. This may be a systemd timer, cron job, or another scheduler.
2. Run a dry test.

sudo certbot renew --dry-run

3. Check whether Nginx needs a reload after renewal. If your client does not handle that automatically, add a deploy hook.
4. Make sure old redirect or challenge rules were not removed during a cleanup.
5. Log the certificate paths in your site documentation.
6. Set a calendar reminder anyway. Automation is good; visibility is better.

What to double-check

This section is the fast preflight review before you issue or renew a certificate. It catches most avoidable failures.

• DNS correctness: The domain resolves to this server, not a previous host or parking page.
• Nginx server selection: The correct server_name matches the requested hostname. Default servers can mask mistakes.
• Firewall reachability: Ports 80 and 443 are open externally, not just locally.
• Challenge path behavior: /.well-known/acme-challenge/ is not blocked by an auth rule, redirect loop, or missing root path.
• Certificate paths: Your ssl_certificate and ssl_certificate_key directives point to the live certificate for the right hostname.
• Nginx syntax: Always run nginx -t before reloads.
• Redirect logic: HTTP redirects to HTTPS once, not through chained or hostname-flipping redirects.
• Canonical hostname plan: Decide whether www or apex is canonical and keep redirects consistent.
• Renewal visibility: You know how renewal runs and where errors would appear in logs.

It is also worth checking whether you are close to issuance limits from repeated failed attempts or frequent re-requests. If you are testing aggressively, review Let’s Encrypt Rate Limits Explained before continuing.

Common mistakes

These are the errors that show up repeatedly in real Nginx SSL work, especially on freshly provisioned VPS instances and recently migrated sites.

1. Requesting a certificate before the site works over HTTP

If the domain does not already reach your Nginx server over port 80, certificate issuance is premature. Always test the plain site path first.

2. Redirecting everything without allowing the ACME challenge

A blanket redirect is fine only if your validation method and Nginx flow support it. In manual setups, add an explicit challenge location or let your client manage temporary rules.

3. Editing the wrong Nginx file

Many servers have multiple include directories, disabled site files, or stale defaults. Verify which file is active before changing SSL directives.

4. Assuming the certificate exists after a failed reload

Issuance and web server reload are separate steps. A certificate may be present on disk even if Nginx failed to load it due to syntax errors or bad permissions.

5. Forgetting the www variant

If users or old links reach both example.com and www.example.com, include both in your request and redirect one cleanly to the other.

6. Reusing snippets blindly

An nginx SSL configuration copied from another server can reference the wrong root, server name, or certificate directory. Reuse patterns, not assumptions.

7. Treating renewal as solved without testing it

The command that worked during setup may not work months later after config cleanup, proxy changes, or domain moves. Dry-run renewal is part of setup, not an afterthought.

8. Mixing proxy behavior and origin behavior

If Cloudflare or another proxy sits in front, make sure you know where TLS is terminated and which server actually answers validation requests. A certificate problem at the origin can be hidden until the proxy is bypassed.

When to revisit

Come back to this checklist whenever one of the underlying inputs changes. Let’s Encrypt on Nginx is stable, but the environment around it rarely stays still.

Revisit before these moments:

• Before a migration to a new VPS, cloud instance, or hosting provider.
• When changing DNS providers, nameservers, or CDN proxy settings.
• When adding new hostnames such as www, staging domains, or regional subdomains.
• When moving from shared hosting habits to VPS administration and managing Nginx directly for the first time.
• When your automation changes such as switching from Certbot to another ACME client.
• Before planned traffic periods when you want to reduce renewal and redirect risk.
• After security hardening changes that alter headers, redirects, access controls, or reverse proxy rules.

A practical maintenance routine is simple:

1. Run certbot renew --dry-run.
2. Run nginx -t.
3. Check that HTTP redirects to the expected HTTPS hostname.
4. Verify the certificate shown in the browser matches the intended domain.
5. Confirm your challenge path would still be reachable if renewal ran today.
6. Document any custom hooks, snippets, and certificate paths for the next admin.

If you need to expand beyond a standard single-site setup, keep related references nearby: DNS-based automation for environments where HTTP-01 is awkward, wildcard guidance for subdomain-heavy projects, and client comparisons for more scripted workflows. That is usually the difference between a setup that works once and one that stays easy to operate.

The durable approach is to keep Nginx readable, redirects minimal, challenge handling deliberate, and renewal tested on purpose. Do that, and Let’s Encrypt becomes routine infrastructure instead of a recurring fire drill.