Let’s Encrypt Setup Guide: Issue Free SSL Certificates with Certbot on Nginx and Apache

Overview

Let’s Encrypt provides certificates through the ACME protocol. Certbot is a commonly used ACME client that can request a certificate and, when its web-server integration is available, update Nginx or Apache for HTTPS. The certificate is free, but successful issuance still depends on correct DNS, a reachable web server, and a configuration that allows the ACME validation request to complete.

This guide assumes that you control a Linux server, have administrative access, and want a certificate for a domain such as example.com and, optionally, www.example.com. Replace those example values with your own domain. If your site is behind a proxy, uses several servers, or needs a wildcard certificate, review the relevant DNS and deployment details before running Certbot.

For a broader certificate, redirect, and renewal diagnostic process, keep the Let’s Encrypt HTTPS troubleshooting checklist available. For wildcard certificates and DNS validation, see the DNS-01 challenge guide.

Checklist by scenario

Scenario 1: A single website on Nginx

1. Confirm DNS first. The domain’s A record should point to the server’s public IPv4 address. If you use IPv6, check the AAAA record as well; an incorrect IPv6 destination can cause validation to reach the wrong server. Confirm that the hostname resolves as expected before proceeding.
2. Open the required traffic paths. Allow inbound HTTP on port 80 and HTTPS on port 443 through the server firewall, cloud security group, and any upstream network firewall. HTTP validation normally needs the domain to be reachable over port 80, even if you intend to redirect visitors to HTTPS later.
3. Check the Nginx server block. Make sure the domain is present in the relevant server_name directive and that the site responds over plain HTTP. Test the configuration with sudo nginx -t, then reload Nginx if necessary.
4. Install Certbot and the Nginx integration. Use the package method supported by your Linux distribution or the current Certbot installation guidance for that system. The required components are Certbot and its Nginx plugin.
5. Request and install the certificate. A typical command is sudo certbot --nginx -d example.com -d www.example.com. Certbot may ask whether to redirect HTTP traffic to HTTPS. Choose the redirect only after confirming that the application works correctly over HTTPS, or apply the redirect yourself after testing.
6. Test both hostnames. Visit each intended hostname using https://. Confirm that the certificate matches the hostname, the page loads, and important assets such as stylesheets, scripts, images, and API calls also use HTTPS.

Scenario 2: A single website on Apache

1. Prepare DNS, ports, and the virtual host. The domain must resolve to the Apache server, and the HTTP virtual host should contain the correct ServerName and any required ServerAlias values. Ensure that Apache is listening on the expected ports.
2. Validate Apache before changing it. Run sudo apachectl configtest. Resolve any syntax errors before requesting a certificate. On systems that use separate modules, confirm that SSL support is available and that the relevant virtual host configuration can be enabled.
3. Install Certbot with the Apache integration. Choose the package and plugin supported by your operating system. The plugin allows Certbot to identify the Apache virtual host and apply certificate settings.
4. Request the certificate. Use a command such as sudo certbot --apache -d example.com -d www.example.com. Review the proposed changes and save a copy of important Apache configuration files before accepting automated edits.
5. Reload and test Apache. After issuance, run the configuration test again and reload Apache. Test HTTPS directly, then confirm that an HTTP request is redirected only if that behavior is intentional and safe for the application.

Scenario 3: The application needs a certificate but should not be edited automatically

Use Certbot in certificate-only mode when you manage the web-server configuration yourself or when automated edits do not fit the deployment. For a webroot-based HTTP challenge, a command may look like sudo certbot certonly --webroot -w /var/www/example -d example.com. The -w path must correspond to the document root that serves the ACME challenge files for that hostname.

After issuance, configure the server to use the certificate and private key paths reported by Certbot. The exact directives differ between Nginx, Apache, containers, and application servers. Protect the private key, test the configuration, and establish a reload step after renewal so the server begins using the renewed certificate.

Scenario 4: HTTP validation is not suitable

Use a DNS-01 challenge when you need a wildcard certificate, the service is not publicly reachable over HTTP, or DNS automation is the better fit. This requires publishing a temporary TXT record under the ACME challenge name. DNS-01 can be powerful, but its automation credentials should be narrowly scoped and stored securely. Follow the DNS-01 and wildcard certificate guide for the validation flow.

What to double-check

• Every required name is included. A certificate for example.com does not automatically cover www.example.com or a separate subdomain. List the hostnames visitors and services actually use.
• DNS is consistent. Check A and AAAA records, CNAME targets, and any DNS proxy or load-balancer settings. If different resolvers return different destinations, validation may be intermittent.
• The challenge path is reachable. Test the domain over HTTP and check whether a firewall, authentication rule, application redirect, or maintenance page blocks the ACME challenge.
• Only one intended server answers. In a load-balanced or migrated environment, every active origin may need to serve the challenge, or validation should be designed around DNS-01.
• HTTPS is configured for the application, not just the web server. Update canonical URLs, callback URLs, webhook endpoints, cookies, and environment variables where appropriate.
• Renewal is testable. Run sudo certbot renew --dry-run after the initial setup. A successful dry run is useful evidence, but it should be paired with monitoring and a plan to reload the web server after renewal.
• CAA records are intentional. If the domain publishes CAA records, verify that they permit the certificate authority you intend to use. See the CAA records guide before changing DNS policy.

Common mistakes

Running Certbot before DNS is ready is a frequent cause of failed validation. Point the domain to the correct server first, then allow for DNS changes to become visible where necessary.

Blocking port 80 can prevent an HTTP-01 challenge even when the final site is intended to use HTTPS only. Keep the validation route available, or use DNS-01 when the architecture requires it.

Requesting a certificate for the wrong hostname produces a valid certificate that does not solve the visitor’s certificate warning. Include aliases explicitly and test each one.

Redirecting too aggressively can interfere with validation or expose application assumptions about proxy headers. Establish HTTPS first, verify the site, and then apply an HTTP-to-HTTPS redirect using a deliberate, tested rule. For implementation examples, see the guide to forcing HTTPS safely.

Ignoring renewal turns a successful installation into a future outage. Check the scheduled renewal mechanism, run a dry run, confirm that the web server reloads after renewal, and decide how certificate failures will generate an alert. A certificate can renew successfully on disk while an already-running process continues using an older certificate until it reloads.

Overlooking mixed content leaves parts of a page loading over HTTP. Update hard-coded asset URLs and inspect browser developer tools after enabling HTTPS. The mixed content guide covers the most common patterns.

When to revisit

Revisit this checklist before moving a site to a new host, adding a subdomain, changing DNS providers, placing the site behind a proxy, or replacing Nginx or Apache with another server. A migration can change the validation path, firewall rules, certificate locations, or renewal hooks even when the domain name stays the same. Use the website migration checklist when changing infrastructure.

Review the setup during regular operational planning as well. Confirm that DNS still points to the intended origin, the renewal dry run still succeeds, HTTPS redirects remain intentional, and monitoring covers certificate expiry and failed renewals. If the workflow or Certbot package changes, consult the current documentation for your operating system rather than copying an old installation command unchanged.

Practical final checklist: verify DNS, open the validation path, test the web-server configuration, issue the certificate for every required hostname, test HTTPS and application assets, run a renewal dry run, and document how the server reloads after renewal. Completing those steps gives you a repeatable Let’s Encrypt setup instead of a one-time certificate installation.