"Certbot Standalone: Get Let's Encrypt SSL on Ubuntu"

Let’s Encrypt is a free, automated certificate authority operated by the nonprofit Internet Security Research Group (ISRG). Certbot standalone mode runs a temporary built-in web server on port 80 to complete the ACME HTTP-01 challenge issued by the Let’s Encrypt API. Use standalone mode when no web server is running on your machine, or when securing a non-HTTP service such as a mail server, an MQTT broker, or a custom TCP application. If a web server such as Nginx or Apache is already running, use the webroot plugin or the Nginx/Apache plugin instead, which complete the challenge without stopping a live service.

In this tutorial, you will use EFF’s Certbot to obtain a valid 90-day certificate issued by Let’s Encrypt, stored at /etc/letsencrypt/live/your_domain/. You will also configure automated renewal using Certbot’s systemd timer and pre/post hook scripts that stop and restart any service occupying port 80 during each renewal attempt.

• Certbot standalone mode runs a temporary built-in web server to answer the Let’s Encrypt ACME challenge. It requires TCP port 80 to be free for the default HTTP-01 challenge.
• Use standalone mode when no web server is running, or when securing a non-HTTP service such as a mail server, message broker, or custom TCP application. Use webroot or the Nginx/Apache plugin when a web server is already serving traffic.
• On Ubuntu 20.04 and later, install Certbot via snap. The EFF no longer actively maintains the apt-based package for current Ubuntu releases.
• Let’s Encrypt certificates are valid for 90 days. The snap-installed Certbot ships a systemd timer that attempts renewal twice daily and renews when a certificate is within 30 days of expiry.
• In standalone mode, port 80 must be free at renewal time. Use pre-hook and post-hook scripts to stop and restart any service that holds the port before and after each renewal attempt.
• Certificate files are stored at /etc/letsencrypt/live/your_domain/. Most services need two files: fullchain.pem (the certificate chain) and privkey.pem (the private key).

Before starting this tutorial, you will need:

• An Ubuntu 20.04 server with a non-root, sudo-enabled user and basic firewall set up, as detailed in How To Do Initial Server Setup with Ubuntu 20.04.
• A domain name pointed at your server. If you are using a DigitalOcean Droplet, you can accomplish this by following our Domains and DNS documentation. This tutorial will use your_domain throughout.
• Port 80 must be available on your server during certificate issuance and each subsequent renewal. If a web server currently occupies port 80, you must stop it before running Certbot in standalone mode and restart it afterward. If the service you want to secure occupies both ports 80 and 443 and you cannot stop it temporarily, use Certbot’s webroot mode instead. For UFW firewall setup, see How To Set Up a Firewall with UFW on Ubuntu.

Start by refreshing the snapd core. Ubuntu 20.04 includes snapd by default:

sudo snap install core; sudo snap refresh core

If you’re working on a server that previously had an older version of certbot installed, you should remove it before going any further:

sudo apt remove certbot

After that, you can install the certbot package:

sudo snap install --classic certbot

Finally, you can link the certbot command from the snap install directory to your path, so you’ll be able to run it by just typing certbot. This isn’t necessary with all packages, but snaps tend to be less intrusive by default, so they don’t conflict with any other system packages by accident:

sudo ln -s /snap/bin/certbot /usr/bin/certbot

Verify the installation by checking the Certbot version:

certbot --version

Output
certbot 2.11.0

The version shown reflects the current snap channel at the time of installation and will change as Certbot releases updates.

Certbot standalone mode answers the ACME HTTP-01 challenge, which requires TCP port 80 to be reachable from the internet. Open port 80 in your firewall:

sudo ufw allow 80

Output
Rule added
Rule added (v6)

Then open port 443 to serve HTTPS traffic after the certificate is issued:

sudo ufw allow 443

Output
Rule added
Rule added (v6)

Standalone mode uses the HTTP-01 challenge on port 80 by default; if you instead use --preferred-challenges tls-alpn-01, open port 443 instead. If port 80 is only needed during certificate issuance and your application does not serve HTTP, close it afterward with sudo ufw delete allow 80.

Use the --standalone option to tell Certbot to handle the challenge using its own built-in web server. The -d flag specifies the domain you’re requesting a certificate for. You can add multiple -d options to cover multiple domains in one certificate.

sudo certbot certonly --standalone -d your_domain

When running the command, you will be prompted to enter an email address and agree to the terms of service. After doing so, you should see a message telling you the process was successful and where your certificates are stored:

Output
IMPORTANT NOTES:
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/your_domain/fullchain.pem
Key is saved at: /etc/letsencrypt/live/your_domain/privkey.pem
This certificate expires on 2026-09-06.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le

Automating Certificate Issuance

For automated or scripted environments where interactive prompts are not available, pass the registration options inline:

sudo certbot certonly --standalone \
  --non-interactive \
  --agree-tos \
  --no-eff-email \
  -m your_email@example.com \
  -d your_domain

--agree-tos accepts the Let’s Encrypt subscriber agreement, --no-eff-email suppresses the EFF newsletter signup prompt, and -m sets the address Let’s Encrypt uses for expiry warnings and renewal failure alerts. Use a real address: renewal failure notifications are the only early warning if the systemd timer stops working.

You should now have your certificates. Use ls to list the directory that holds your keys and certificates:

sudo ls /etc/letsencrypt/live/your_domain

Output
cert.pem  chain.pem  fullchain.pem  privkey.pem  README

Verify the certificate details with openssl:

sudo openssl x509 -in /etc/letsencrypt/live/your_domain/cert.pem -noout -subject -issuer -dates -ext subjectAltName

Output
subject=CN = your_domain
issuer=C = US, O = Let's Encrypt, CN = E5
notBefore=Mon Jun  8 00:00:00 2026 GMT
notAfter=Sun Sep  6 00:00:00 2026 GMT

X509v3 Subject Alternative Name:
    DNS:your_domain

notAfter confirms the 90-day validity window. issuer confirms that Let’s Encrypt signed the certificate. If you issued for multiple domains using repeated -d flags, all domains appear here as separate DNS: entries. A domain missing from this list is not covered by the certificate.

To list all certificates currently managed by Certbot, including their domains and expiry dates, run:

sudo certbot certificates

Output
Found the following certs:
  Certificate Name: your_domain
    Serial Number: ...
    Key Type: ECDSA
    Domains: your_domain
    Expiry Date: 2026-09-06 00:00:00+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/your_domain/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/your_domain/privkey.pem

This is the primary command to check certificate status on any server managed by Certbot.

Configuring a Service to Use the Certificate

Most services require two files from this directory: fullchain.pem as the certificate and privkey.pem as the private key. The following example shows the relevant TLS directives for Postfix in /etc/postfix/main.cf:

smtpd_tls_cert_file = /etc/letsencrypt/live/your_domain/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/your_domain/privkey.pem
smtpd_tls_security_level = may

For an MQTT broker such as Mosquitto, add the following to /etc/mosquitto/conf.d/tls.conf:

listener 8883
cafile /etc/ssl/certs/ca-certificates.crt
certfile /etc/letsencrypt/live/your_domain/fullchain.pem
keyfile /etc/letsencrypt/live/your_domain/privkey.pem

Port 8883 is the standard MQTT-over-TLS port. The same root-only permissions caveat applies: the mosquitto user requires a deploy hook or explicit read access to privkey.pem.

The README file in this directory has more information about each of these files. Most often you’ll only need two of these files:

• privkey.pem: The private key. Keep this secret. The /etc/letsencrypt directory is root-only for this reason. Most services refer to it in configuration as ssl-certificate-key or ssl-certificate-key-file.
• fullchain.pem: The full certificate chain. Most services refer to it as ssl-certificate.

For more information on the other files present, refer to the Where are my certificates? section of the Certbot docs.

Some software will need its certificates in other formats, in other locations, or with other user permissions. It is best to leave everything in the letsencrypt directory, and not change any permissions in there (permissions will just be overwritten upon renewal anyway), but sometimes that’s just not an option. In that case, you’ll need to write a script to move files and change permissions as needed. This script will need to be run whenever Certbot renews the certificates, which the next step covers.

Let’s Encrypt certificates are valid for 90 days. The snap-installed Certbot registers a systemd timer (snap.certbot.renew.timer) that runs certbot renew twice daily and renews any certificate within 30 days of expiry. No manual cron setup is required.

After renewal, Certbot needs to reload or restart any service using the certificate to pick up the new files. In standalone mode, it also needs to stop any service holding port 80 before the renewal attempt and restart it afterward. Certbot provides two mechanisms for this: the renew_hook option in the renewal configuration file, and pre/post hook scripts in the renewal-hooks directories.

To add a renew_hook, open Certbot’s renewal configuration file for your domain:

sudo nano /etc/letsencrypt/renewal/your_domain.conf

A text file will open with some configuration options. You can add a hook on the last line that will reload any web-facing services, making them use the renewed certificate:

renew_hook = systemctl reload your_service

Update the command above to whatever you need to run to reload your server or run any post-renewal file processing script. Usually, on Ubuntu, you’ll mostly be using systemctl to reload a service.

Using Pre-Hook and Post-Hook Scripts for Service Restarts

In standalone mode, each renewal attempt must bind to port 80 again to complete the ACME challenge. If a service occupies port 80 at renewal time, the renewal fails and the certificate eventually expires. Pre-hooks stop the service before the renewal attempt; post-hooks restart it after.

Before choosing an approach, note the downtime tradeoff: in standalone mode, Certbot must bind to port 80 for a few seconds during the ACME challenge. Any service stopped by the pre-hook is unavailable for that window plus the time to stop and restart. For most non-HTTP services (mail, MQTT, custom TCP), this is acceptable. If zero-downtime renewal is required, use a reverse proxy that forwards /.well-known/acme-challenge/ to Certbot’s --http-01-port while your service continues running, but that configuration is outside the scope of this tutorial.

When choosing between the two hook approaches below: use the renewal-hooks directory approach (Approach 1) if you want hooks to run regardless of how renewal is triggered. Use the inline flags approach (Approach 2) if you want the hook stored in the renewal config file and are issuing the certificate interactively. For standalone mode securing a non-HTTP service, Approach 1 is the safer choice.

Approach 1: Hook scripts in the renewal-hooks directories (recommended for standalone mode).

Create the pre-hook script:

sudo tee /etc/letsencrypt/renewal-hooks/pre/stop-service.sh <<'EOF'
#!/bin/sh
systemctl stop your_service
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/pre/stop-service.sh

Create the post-hook script:

sudo tee /etc/letsencrypt/renewal-hooks/post/start-service.sh <<'EOF'
#!/bin/sh
systemctl start your_service
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/post/start-service.sh

Certbot processes scripts in these directories based on when they run relative to a renewal attempt:

• /etc/letsencrypt/renewal-hooks/pre/: runs before every renewal attempt, whether or not the certificate is actually renewed.
• /etc/letsencrypt/renewal-hooks/deploy/: runs only when a certificate is successfully renewed and deployed.
• /etc/letsencrypt/renewal-hooks/post/: runs after every renewal attempt, regardless of outcome.

Approach 2: Inline flags at certificate issuance (stored in the renewal config).

sudo certbot certonly --standalone \
  --pre-hook "systemctl stop your_service" \
  --post-hook "systemctl start your_service" \
  -d your_domain

Certbot writes these flags to /etc/letsencrypt/renewal/your_domain.conf automatically, so they apply on every subsequent certbot renew run.

Verifying the Renewal Timer

Check that the systemd timer is active and confirm its next scheduled run:

sudo systemctl list-timers | grep certbot

Output
NEXT                        LEFT     LAST                        PASSED   UNIT                       ACTIVATES
Tue 2026-06-09 12:00:00 UTC 5h left  Mon 2026-06-08 00:00:00 UTC 6h ago  snap.certbot.renew.timer   snap.certbot.renew.service

Run a dry-run renewal to confirm the configuration works without issuing a new certificate:

sudo certbot renew --dry-run

Output
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/your_domain/fullchain.pem (success)

If you see no errors, Certbot is set to renew when necessary and run any commands needed to get your service using the new certificate files. Note that --dry-run runs pre and post hooks but skips deploy hooks. If you configured a renew_hook in the renewal configuration file rather than pre/post scripts, it will not run during a dry-run since no certificate is actually issued.

Choose the mode that matches whether a web server is already running on your machine and whether you need automatic web server configuration updates.

If a web server is already running on your machine, prefer the webroot plugin or the Nginx/Apache plugin over standalone to avoid stopping a live service during renewal. For Nginx, see How To Secure Nginx with Let’s Encrypt on Ubuntu 20.04. For Apache, see How To Secure Apache with Let’s Encrypt on Ubuntu 20.04. If you are running Ubuntu 22.04, the standalone workflow is documented at How To Use Certbot Standalone Mode on Ubuntu 22.04.

Port 80 Already in Use (EADDRINUSE)

If another process is bound to port 80, Certbot fails with an OSError: [Errno 98] Address already in use error. Identify the process holding the port:

sudo ss -tlnp 'sport = :80'

Output
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=1234,fd=6))

Stop the offending service (example: Nginx):

sudo systemctl stop nginx

Then re-run the certbot certonly --standalone command. After the certificate is issued, restart the service:

sudo systemctl start nginx

Firewall Blocking Port 80

The ACME HTTP-01 challenge fails if Let’s Encrypt’s servers cannot reach port 80 on the public IP of your domain. Check the current UFW status:

sudo ufw status

Output
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
443                        ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)

If port 80 is not listed as allowed, open it:

sudo ufw allow 80

Output
Rule added
Rule added (v6)

After the certificate is issued, remove the rule if your application does not serve HTTP:

sudo ufw delete allow 80

Output
Rule deleted
Rule deleted (v6)

IPv4/IPv6 Dual-Stack Binding Errors

In some Docker environments and VPS configurations, Certbot may fail to bind to port 80 due to IPv4/IPv6 dual-stack conflicts. The error typically reads: Problem binding to port 80: Could not bind to IPv4 or IPv6. Use the --preferred-challenges flag to force the HTTP-01 challenge explicitly:

sudo certbot certonly --standalone --preferred-challenges http-01 -d your_domain

If running inside a Docker container, ensure port 80 is mapped from the container to the host and that no host-level process is also binding port 80.

Challenge Fails with Port 80 Open (DNS/IPv6 Mismatch)

If Certbot returns an error such as Connection refused or Timeout during connect even though UFW shows port 80 as allowed, the cause is often a DNS AAAA record. Let’s Encrypt prefers IPv6 and will attempt to reach your domain over IPv6 first. If your domain has an AAAA record pointing to an address that is not actually serving port 80, the challenge fails regardless of your IPv4 firewall rules.

Check whether your domain has an AAAA record:

dig AAAA your_domain

Output
;; ANSWER SECTION:
your_domain.    300    IN    AAAA    2001:db8::1

If the AAAA record exists but your server does not have IPv6 configured, either remove the AAAA record from your DNS provider or ensure the server’s IPv6 address is also listening on port 80. To confirm IPv6 port 80 availability:

sudo ss -tlnp 'sport = :80'

Output
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=1234,fd=6))
LISTEN 0      511             [::]:80            [::]:*     users:(("nginx",pid=1234,fd=6))

Both an IPv4 (0.0.0.0:80) and IPv6 ([::]:80) entry should appear if your server is dual-stack. If only the IPv4 entry is present and an AAAA record exists, Let’s Encrypt’s challenge will fail.

What Is Certbot Standalone Mode and When Should I Use It?

In standalone mode, Certbot temporarily occupies port 80 and places a verification token at a well-known URL. Let’s Encrypt fetches that token to confirm you control the domain and then issues the certificate. Use standalone mode when no web server is running on your system, or when you are securing a non-HTTP service such as a mail server, an MQTT broker, or a custom TCP application.

Do I Need to Stop My Web Server Before Running Certbot in Standalone Mode?

Yes. Certbot standalone mode binds to port 80 to handle the ACME challenge. If Nginx or Apache is already bound to port 80, Certbot fails with a binding error. Stop the web server before running sudo certbot certonly --standalone, then restart it after the certificate is issued.

How Do I Renew a Let’s Encrypt Certificate Obtained with Standalone Mode?

The snap-installed Certbot on Ubuntu 20.04 registers a systemd timer (snap.certbot.renew.timer) that runs certbot renew twice daily. For standalone mode, configure pre-hook and post-hook scripts to stop and restart any service that occupies port 80, using either the --pre-hook and --post-hook flags or scripts placed in /etc/letsencrypt/renewal-hooks/. Test the process with sudo certbot renew --dry-run.

Where Are the Certificate Files Stored After Certbot Issues Them?

Certificates are stored in /etc/letsencrypt/live/your_domain/. The files most services require are fullchain.pem (the full certificate chain to pass to the service as the SSL certificate), privkey.pem (the private key), cert.pem (the end-entity certificate only), and chain.pem (the intermediate chain only).

What Happens If Port 80 Is Blocked by a Firewall During Certificate Issuance?

The ACME HTTP-01 challenge fails because Let’s Encrypt’s servers cannot reach port 80 on your domain. Open port 80 with sudo ufw allow 80, run the certbot command, then close it again with sudo ufw delete allow 80 if your application does not serve HTTP.

Can I Use Certbot Standalone Mode Inside a Docker Container?

Yes, but port 80 must be mapped from the container to the host, and no host-level process can be binding port 80 simultaneously. IPv4/IPv6 dual-stack issues can cause binding failures in Docker environments. If you encounter a dual-stack error, ensure your container network configuration allows correct port mapping, or pass --preferred-challenges http-01 to force the HTTP-01 challenge explicitly.

How Long Is a Let’s Encrypt Certificate Valid, and How Often Does It Renew?

Let’s Encrypt certificates are valid for 90 days. Certbot’s systemd timer attempts renewal when the certificate is within 30 days of expiry. If the pre/post hooks are correctly configured and port 80 is available at renewal time, no manual intervention is required.

Is Snap the Recommended Way to Install Certbot on Ubuntu 20.04?

Yes. The EFF recommends installing Certbot via snap on Ubuntu 20.04 and later. The python3-certbot apt package is no longer actively maintained upstream. Installing via snap ensures you receive the latest Certbot releases automatically through the snap refresh mechanism.

In this tutorial, you installed Certbot via snap on Ubuntu 20.04, configured the firewall to allow the ACME HTTP-01 challenge on port 80 and HTTPS traffic on port 443, obtained a certificate with certbot certonly --standalone, verified the certificate details with openssl, and configured automatic renewal using pre-hook and post-hook scripts alongside the Certbot systemd timer.

The certificate files at /etc/letsencrypt/live/your_domain/ are now available to configure TLS for any service running on your server. The certificate renews automatically without manual intervention, provided the pre/post hooks keep port 80 free during each renewal attempt.

For next steps, refer to the following resources:

• For Nginx: How To Secure Nginx with Let’s Encrypt on Ubuntu 20.04
• For Apache: How To Secure Apache with Let’s Encrypt on Ubuntu 20.04
• For Ubuntu 22.04: How To Use Certbot Standalone Mode on Ubuntu 22.04
• Certbot documentation: https://eff-certbot.readthedocs.io/en/stable/