Let's Encrypt on Ubuntu: Step-by-Step Setup for Current LTS Releases

Overview

This article gives you a practical checklist for installing Let’s Encrypt on Ubuntu with Certbot and enabling HTTPS with minimal guesswork. It is written for current Ubuntu LTS releases in a way that stays useful even as package details shift over time.

The core workflow rarely changes:

• Point the domain to the Ubuntu server.
• Confirm the site loads over plain HTTP first.
• Install Certbot using the method appropriate for the server.
• Request the certificate using the correct challenge type.
• Enable HTTPS and redirect HTTP to HTTPS.
• Test automatic renewal before calling the job done.

If you remember only one idea, make it this: Let’s Encrypt is not just a certificate installation task. It is a deployment workflow that depends on DNS, networking, web server configuration, and renewal automation all working together.

For most Ubuntu deployments, Certbot is still the simplest starting point. If your setup is unusual, containerized, or heavily automated, you may also want to compare alternatives later in your process: Certbot Alternatives for 2026: When to Use acme.sh, Dehydrated, Win-ACME, or Caddy.

Before you begin

• An Ubuntu LTS server you can access with sudo.
• A domain or subdomain already pointing to the server’s public IP.
• A working web server such as Nginx or Apache, unless you plan to use a standalone validation method.
• Ports 80 and 443 reachable from the internet.
• A basic plan for renewal monitoring.

It also helps to know which validation path you intend to use:

• HTTP-01: best for normal websites reachable on port 80.
• DNS-01: best for wildcard certificates or environments where HTTP validation is inconvenient.
• Standalone: useful when Certbot temporarily binds its own validation listener.

If you are not sure, start with HTTP-01 for a standard public website. Move to DNS-01 only when you need wildcard coverage, more automation across hosts, or tighter separation between the web server and certificate workflow.

Checklist by scenario

Use the scenario below that matches your Ubuntu server. Each checklist is written to be reusable before a new deployment, a migration, or a renewal audit.

Scenario 1: Single website on Ubuntu with Nginx

This is the cleanest path for a typical VPS or cloud instance running one site.

1. Confirm DNS first. Verify that the A or AAAA record for the domain points to the correct server. If you recently changed providers, allow time for propagation and confirm you are hitting the intended host.
2. Make sure Nginx serves the domain over HTTP. Before requesting a certificate, the site should respond on port 80 with the correct server block. If it serves the wrong default site, fix that first.
3. Check firewall rules. On Ubuntu, confirm that ports 80 and 443 are allowed. If a cloud firewall or provider security group exists, check that too.
4. Install Certbot and the Nginx integration. Use the current package method recommended for your Ubuntu release and environment. The exact package source may change over time, so follow the maintained method for your release rather than relying on an old tutorial.
5. Request the certificate using the Nginx plugin if appropriate. This is the simplest route because it can edit server configuration and set redirects for you.
6. Review the generated TLS settings. Confirm the certificate paths, the listening directives for 443, and the redirect from HTTP to HTTPS.
7. Reload Nginx and test. Visit the site over HTTPS, then inspect the certificate details and any redirect chain.
8. Run a renewal dry run. Do not skip this. A successful first issuance does not guarantee the renewal path will work later.

For a deeper Nginx-specific walkthrough, keep this companion guide handy: Let’s Encrypt for Nginx: Complete Setup, Redirects, and Renewal Checklist.

Scenario 2: Single website on Ubuntu with Apache

Apache is equally workable, but the main difference is where redirects and virtual host settings live.

1. Verify the domain resolves correctly. Do this before touching Apache.
2. Confirm the site responds on port 80. If the wrong virtual host answers, fix name-based host matching before attempting validation.
3. Enable the required Apache modules. On many systems, SSL and rewrite-related modules must be available for a clean HTTPS deployment.
4. Install Certbot and the Apache integration. As with Nginx, use the maintained installation path for the Ubuntu LTS release in use.
5. Request the certificate for the exact hostnames you need. Include both apex and www only if both resolve to the server and are intended to be covered.
6. Review virtual host changes. Check the SSL virtual host, certificate file paths, and redirect behavior.
7. Restart or reload Apache and verify. Confirm the right site loads on HTTPS and that mixed-content issues are not hiding beneath a successful certificate installation.
8. Test renewal. Treat this as part of setup, not a later maintenance task.

If Apache is your main stack, this related article goes deeper: Let’s Encrypt for Apache: Complete Setup, VirtualHosts, and Renewal Checklist.

Scenario 3: Multi-site Ubuntu server

When several domains live on one host, the risk is usually not issuance itself but mis-targeting the wrong vhost, missing one hostname, or introducing a redirect loop.

1. List every hostname deliberately. Separate what must be covered from what only exists historically. Avoid issuing broad certificates out of habit.
2. Confirm each hostname resolves to this server. A single missing DNS record can break a multi-name request.
3. Check the web server mappings. Each domain should already map to the correct document root or upstream before you add HTTPS.
4. Issue certificates per site or per logical group. Simpler certificate boundaries often make renewal and troubleshooting easier.
5. Document certificate ownership. On a server with many apps, record which service owns which cert and where the config lives.
6. Test renewals across all managed certificates. One broken vhost can quietly fail while others continue working.

If you need broader visibility after deployment, add certificate monitoring early: Let’s Encrypt Expiry Monitoring: Best Tools, Alerts, and Dashboard Options.

Scenario 4: Wildcard certificate on Ubuntu

Wildcard certificates are useful, but they require DNS-01 validation rather than the normal HTTP flow.

1. Decide whether you actually need a wildcard. If you only host a few stable names, explicit hostnames may be easier to manage.
2. Prepare DNS access. You need the ability to create TXT records manually or through provider automation.
3. Use a DNS-01-capable Certbot workflow or another ACME client. The exact plugin choice depends on your DNS provider and how much automation you want.
4. Protect API credentials carefully. If you use provider tokens, store them with restrictive file permissions and clear ownership.
5. Verify renewal automation. DNS-based issuance is powerful, but only if the TXT update path is still valid months later.

For provider-specific automation patterns, see Let’s Encrypt DNS-01 Automation by Provider: Cloudflare, Route 53, DigitalOcean, and More and for wildcard planning, see Let’s Encrypt Wildcard Certificates: DNS-01 Setup, Limits, and Renewal Tips.

Scenario 5: Ubuntu server behind a proxy, CDN, or load balancer

This is where many otherwise correct tutorials stop being helpful. Validation and certificate placement depend on where traffic terminates.

1. Identify the TLS termination point. If HTTPS terminates at a proxy or CDN, decide whether the origin server still needs its own certificate.
2. Understand the validation path. HTTP-01 must reach the expected origin response. Reverse proxies, WAF rules, or forced redirects can interfere.
3. Check origin reachability. If the public request never reaches the Ubuntu box directly, standalone validation may fail unless routing rules allow it.
4. Prefer DNS-01 when the HTTP path is hard to control. This often simplifies issuance for layered network setups.
5. Test from outside the network. Internal success does not prove public validation will work.

If HTTP validation keeps failing, use this troubleshooting reference: How to Fix Let’s Encrypt HTTP-01 Challenge Failures.

What to double-check

This section is the short list to review before you request a certificate and again before you leave the server unattended.

DNS is pointing to the right place

The most common issue is simple: the hostname resolves somewhere else. Double-check apex records, www records, IPv6 records if present, and any stale DNS entries from a previous host. If email is involved on the same domain, do not change unrelated MX or TXT records while troubleshooting web validation.

Your server answers on port 80 before HTTPS exists

HTTP-01 validation expects a plain HTTP path to work. If you enforce unusual rewrite rules, return only a generic error page, or expose a placeholder default site, validation can fail even though the server is online.

The web server config matches the certificate names

If you request a certificate for example.com and www.example.com, both names should be expected in your live configuration. A certificate should reflect the real site topology, not a wish list of hostnames.

Automatic renewal is enabled and testable

Successful issuance is not the finish line. Check that the renewal mechanism exists, that it runs under the expected scheduler, and that the reload hook for Nginx or Apache behaves cleanly. A dry run is the simplest proof. For a detailed operational checklist, see How to Renew Let’s Encrypt Certificates Automatically and Verify It Actually Works.

Your application is ready for HTTPS

After the certificate is in place, application-level issues can still break the experience. Watch for mixed content, hard-coded http:// asset URLs, insecure upstream references, or redirect loops caused by reverse proxy headers.

Headers and redirects are deliberate

Once HTTPS works, set the redirect from HTTP to HTTPS cleanly and check any security headers you plan to use. Avoid copying a large header bundle blindly; test changes with your application and deployment style.

Common mistakes

If your Ubuntu Let’s Encrypt setup fails, it is usually because one of a small number of assumptions is wrong. These are the mistakes worth checking first.

Installing Certbot before the site is reachable

Many admins start with package installation and only later discover the domain still points to an old host. Validate network reachability first. It reduces noise and makes Certbot errors easier to interpret.

Requesting certificates for hostnames that should not be included

Including unused names adds complexity and increases the chance of DNS or validation errors. Keep certificate requests narrow and intentional.

Relying on one successful issuance without testing renewal

This is the classic failure mode. The first request works during manual setup, then renewal fails later because firewall rules changed, a plugin path broke, or a DNS token expired.

Breaking validation with redirects or proxy rules

A redirect to another hostname, a forced HTTPS pattern that does not preserve challenge handling, or a CDN rule that caches incorrectly can all interfere with HTTP-01 validation.

Using wildcard certificates without planning DNS automation

Wildcard certificates can look cleaner, but they shift the burden to DNS. If your provider workflow is awkward or manual, renewal can become fragile quickly.

Assuming Ubuntu release changes do not matter

The broad process stays stable, but package sources, plugin names, and service management details can shift between LTS cycles. Each time you deploy on a new Ubuntu LTS release, treat the installation method as something to verify rather than assume.

Forgetting the application layer

Certbot can complete successfully while the site still shows browser warnings from mixed content, bad redirect logic, or incorrect upstream scheme detection. HTTPS deployment is not done until the application behaves correctly under HTTPS.

If you are deploying WordPress on Ubuntu, HTTPS issues often continue above the server layer. This guide helps with those specifics: Let’s Encrypt for WordPress: Hosting Requirements, Plugin Options, and HTTPS Fixes.

When to revisit

Use this final checklist whenever the server, domain, or certificate workflow changes. This is the part most worth bookmarking.

Revisit before a new Ubuntu LTS deployment

Even if you have installed Let’s Encrypt dozens of times, review the package and plugin approach before building on a new Ubuntu LTS release. The issuance logic may be familiar, but the supported installation path can change.

Revisit when moving hosts or changing IP addresses

If you migrate to a new VPS, cloud instance, or load balancer, re-check DNS, firewall rules, vhost mappings, and challenge reachability before cutover. This is also a good time to compare hosting environments if you expect to manage multiple certificates: Best Hosting for Let’s Encrypt Support: Shared, VPS, Cloud, and Managed Options.

Revisit when adding domains, subdomains, or a wildcard

Do not just append names because they exist. Review whether you need a new certificate, a broader certificate, or a DNS-based workflow.

Revisit when renewal tooling changes

If you switch web servers, replace Certbot, alter scheduler behavior, or move DNS providers, run a fresh renewal dry run and confirm the deployment hooks still reload services correctly.

Revisit before traffic peaks or maintenance freezes

If your site has seasonal traffic, launch windows, or internal change freezes, audit certificate expiry dates and renewal logs in advance rather than during the critical period. Pair that with certificate monitoring so you are not depending on memory alone.

Practical action list

• Confirm the domain resolves to the intended Ubuntu server.
• Check that HTTP works before requesting a certificate.
• Use the appropriate Certbot integration for Nginx, Apache, or DNS validation.
• Request only the hostnames you actually need.
• Enable HTTPS and verify redirects.
• Run a renewal dry run immediately.
• Set up expiry monitoring and document where certificate config lives.

If you treat Let’s Encrypt on Ubuntu as an operational checklist rather than a one-time command sequence, your deployments become much more predictable. That is the real goal: not just getting a free SSL certificate once, but having a repeatable Ubuntu HTTPS setup you can trust the next time you rebuild, migrate, or upgrade.