How to Install and Renew a Let’s Encrypt SSL Certificate on Nginx and Apache

Overview

HTTPS protects the connection between a visitor’s browser and your web server. A Let’s Encrypt certificate provides the certificate needed for that encrypted connection, while an ACME client such as Certbot handles certificate requests and, in many configurations, web-server integration and renewal.

A successful setup has four separate parts:

1. Domain readiness: the domain names in the certificate resolve to the server or validation endpoint you intend to use.
2. Certificate issuance: an ACME client proves control of the domain and obtains a certificate.
3. Web-server configuration: Nginx or Apache presents the certificate for HTTPS connections.
4. Renewal and redirection: the certificate is renewed before it expires, and HTTP traffic is redirected only after HTTPS works correctly.

Before changing configuration, record the exact hostnames you need to protect. Decide whether the certificate should cover the apex domain, such as example.com, the www hostname, subdomains, or a combination. A certificate for one hostname does not automatically cover every other hostname. For a broader comparison of single-domain, SAN, and wildcard approaches, see Let’s Encrypt for subdomains.

You should also confirm that inbound HTTP and HTTPS traffic can reach the intended server, that the web server is running, and that no unrelated service is already occupying the required ports. If DNS is managed separately from hosting, check the A and AAAA records as well as any proxy or CDN settings before beginning.

Checklist by scenario

Scenario 1: A new certificate on Nginx

1. Install an ACME client using the supported method for your operating system. Certbot packages and plugin names differ between distributions, so follow the package guidance for your platform rather than copying an unrelated repository command.
2. Confirm that Nginx has a server block for each hostname. For example, check that server_name example.com www.example.com; matches the names you plan to request.
3. Test the existing configuration before requesting a certificate:

sudo nginx -t

4. Request the certificate with the Nginx integration when appropriate:

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

The client may offer to update the Nginx configuration and create an HTTP-to-HTTPS redirect. Review the proposed changes. If you prefer to separate certificate issuance from configuration changes, use a certificate-only workflow and configure the server manually.

After installation, test both the syntax and the live response:

sudo nginx -t
curl -I https://example.com

A successful response is useful, but it does not prove that every hostname, application path, or asset is correct. Test the canonical hostname and any alternate hostname you intend to keep accessible.

Scenario 2: A new certificate on Apache

1. Enable the modules and site configuration required by your operating system’s Apache package. Common requirements include SSL support and the rewrite module, but module names and commands vary.
2. Make sure the virtual host includes the intended names, for example with ServerName and ServerAlias.
3. Check the Apache configuration before requesting a certificate:

sudo apachectl configtest

4. Request and install the certificate through the Apache integration:

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

Review any redirect option before accepting it. Then test the configuration again and reload Apache using the service command appropriate for your system:

sudo apachectl configtest
sudo systemctl reload apache2

Some systems use a different service name, such as httpd. A reload is generally preferable to a restart when you only need to apply a valid configuration change, but always follow your operating system’s service conventions.

Scenario 3: Renewal on an existing installation

Do not wait for an expiration warning to discover that renewal is broken. First list the certificates managed by your ACME client:

sudo certbot certificates

Then perform a dry run:

sudo certbot renew --dry-run

A dry run checks the renewal workflow without replacing the production certificate. If it fails, read the complete error output and verify DNS, firewall rules, webroot paths, permissions, and any reverse proxy or CDN involved in validation. Only investigate a successful dry run as a starting point; also confirm that a timer, scheduled task, or hosting control panel is actually invoking renewal.

For a deeper operational checklist, see how to renew a Let’s Encrypt certificate automatically with Certbot.

Scenario 4: Manual or non-Certbot deployment

If you use another ACME client, a container, a control panel, or a cloud load balancer, do not run overlapping certificate automation without understanding which process owns the certificate. Identify the certificate directory, renewal command, deployment hook, and reload command. The critical requirement is that a renewed certificate is copied or exposed to the service that terminates TLS, followed by a safe configuration reload.

What to double-check

• DNS: A and AAAA records should lead validation and visitor traffic to the correct endpoint. An outdated AAAA record can cause some networks to reach a different server.
• Validation access: HTTP-based validation may require the server to answer on port 80, even if your finished site redirects HTTP to HTTPS. Do not block the validation path with authentication, an application error, or an overly broad redirect rule.
• CAA records: If your DNS zone contains CAA records, confirm that they permit the certificate authority you intend to use. See the CAA records guide before changing them.
• Proxy layers: If a CDN or reverse proxy sits in front of Nginx or Apache, determine where the certificate is installed. Installing it on the origin server does not necessarily change the certificate presented by the proxy.
• Redirect logic: Redirect HTTP to the final HTTPS URL with one clear redirect. Preserve the path and query string, and avoid redirecting an HTTPS request back to HTTP because the application does not understand forwarded protocol headers.
• Application URLs: Update hard-coded HTTP links, canonical URLs, form actions, scripts, images, and stylesheets. Otherwise, browsers may report mixed-content warnings after the certificate is installed. Use the mixed-content troubleshooting guide if needed.
• Monitoring: Check certificate expiry, renewal task results, service reload errors, and HTTPS availability. A certificate can renew successfully while the web server continues presenting an older certificate if deployment is misconfigured.

Common mistakes

Requesting the wrong hostnames. A certificate request for www.example.com does not prove that example.com is covered. Include every production hostname or redirect unused names deliberately.

Changing DNS and issuing immediately. DNS changes may not be visible everywhere at once. Confirm that public resolvers return the expected records before troubleshooting the ACME client.

Redirecting before HTTPS works. If HTTP redirects to a broken HTTPS virtual host, visitors can be trapped in an outage. Validate HTTPS directly first, then enable the redirect.

Editing generated configuration without a plan. ACME integrations may manage certificate paths or virtual-host settings. Keep a backup, understand which files are authoritative, and test with nginx -t or apachectl configtest before reloading.

Testing renewal only by forcing production renewal. Use the client’s dry-run facility first. Repeated unnecessary production requests can create operational and rate-limit problems, while a dry run is designed for routine testing.

Forgetting non-web services. Mail, APIs, administrative panels, and subdomains may have separate TLS endpoints. Review each service rather than assuming the main website’s certificate covers the whole domain.

If an error message is unclear, preserve the complete client output, the affected hostname, the validation method, and the relevant web-server logs. The Let’s Encrypt error codes guide can help map common ACME failures to the next diagnostic step.

When to revisit

Return to this checklist whenever you add a hostname, change DNS providers, move to a new host, introduce a CDN or load balancer, change firewall rules, or replace Nginx, Apache, or the ACME client. Revisit it before planned migration or seasonal traffic work so certificate deployment is tested before the change becomes urgent. The website migration checklist is useful when the server or DNS endpoint is changing.

As a recurring operational task, confirm that:

1. the certificate covers all production hostnames;
2. HTTPS serves the expected certificate from the public endpoint;
3. HTTP redirects cleanly to HTTPS;
4. the renewal dry run succeeds;
5. the renewal scheduler is enabled and logs are reviewed; and
6. the web server reloads successfully after renewal.

Finally, document who or what owns certificate renewal, where the configuration is stored, and how to roll back a failed change. That short record turns a one-time Let’s Encrypt setup into a repeatable HTTPS maintenance process.