Which challenge type should I use?

Use webroot if your web server is already running and serving the domain (Certbot drops a file it and Let's Encrypt can both reach); use standalone only when no web server is listening on port 80 yet, since it briefly binds that port itself; use DNS-01 when you need a wildcard certificate or the domain isn't publicly reachable over HTTP at all.

Why does standalone mode stop and restart the web server?

Certbot's standalone plugin runs its own temporary web server to answer the HTTP-01 challenge, and it needs port 80 free to do that. If Nginx or Apache is already bound to port 80, Certbot will fail to start unless that service is stopped first and restarted afterward, which the generated commands do explicitly.

Do I need a DNS plugin for DNS-01, or can Certbot do it manually?

Certbot can walk you through manually creating a TXT record, but that can't be automated for renewal. For automatic renewal you need a DNS provider plugin (e.g. certbot-dns-cloudflare, certbot-dns-route53) that can create the TXT record via API; the generated snippet shows the Cloudflare plugin as a concrete example.

This only issues the certificate, how do I set up auto-renewal?

Use the separate Certbot Renewal Config Generator, which produces the systemd timer and cron snippet for keeping the certificate this tool issues renewed automatically.

Certbot Certificate Command Generator - Webroot, Standalone, DNS-01

Overview

Introduction

Getting a Let's Encrypt certificate is usually one Certbot command, but which command depends on which challenge type fits your setup and which web server you're running, two small decisions that change the flags enough to trip up a first-time run.

This tool generates the install command and the correct certonly invocation for your challenge type and web server, so issuing a first certificate is one paste.

What Is Let's Encrypt Config Generator?

A generator for Certbot's install command (with the matching Nginx or Apache plugin package) and the certonly command for the HTTP-01 webroot challenge, the HTTP-01 standalone challenge, or the DNS-01 challenge.

It also shows the resulting certificate file paths so you know where to point your web server config once the certificate is issued.

How Let's Encrypt Config Generator Works

You provide the domain, a contact email, pick a challenge type, and pick Nginx or Apache. The generator validates the domain and email formats.

It then emits the apt install command with the matching plugin package and the certonly command shaped for the chosen challenge (webroot path, standalone start/stop, or DNS-01 with a plugin placeholder), plus the certificate file paths.

When To Use Let's Encrypt Config Generator

Use it when issuing a first Let's Encrypt certificate for a domain and you want the exact command for your challenge type and web server.

Pair it with the Certbot Renewal Config Generator once the certificate is issued, to keep it renewing automatically.

Often used alongside Certbot Renewal Config Generator, Nginx Reverse Proxy Generator and Apache VirtualHost Generator.

Features

Advantages

Matches the install plugin package to the chosen web server (python3-certbot-nginx vs python3-certbot-apache) automatically.
Standalone mode includes the stop/start commands around certonly, a step that's easy to forget and causes a confusing port-80-in-use failure otherwise.
Shows the exact certificate file paths Certbot will produce, so you know what to reference in your web server config.

Limitations

The DNS-01 snippet uses Cloudflare's plugin as a concrete example; a different DNS provider needs its own plugin package and credentials file format.
Doesn't generate the actual web server config block that serves over the new certificate, or the renewal automation, pair it with the Nginx, Apache, or Caddy config generators and the Certbot Renewal Config Generator for those.

Examples

Webroot challenge on Nginx

Input

domain: example.com, email: admin@example.com, challengeType: webroot, webServer: nginx, webrootPath: /var/www/html

Output

sudo apt update && sudo apt install -y certbot python3-certbot-nginx

sudo certbot certonly --webroot -w /var/www/html -d example.com --email admin@example.com --agree-tos --no-eff-email

Webroot mode needs no service interruption since Certbot just drops a file for Let's Encrypt to fetch through the already-running Nginx.

Best Practices & Notes

Best Practices

Prefer webroot over standalone whenever a web server is already serving the domain, to avoid any downtime during issuance.
Use DNS-01 for wildcard certificates (*.example.com), since HTTP-01 challenges can't validate a wildcard.
Set up the renewal timer or cron job right after issuance instead of leaving it for later, using the Certbot Renewal Config Generator.

Developer Notes

Certbot's HTTP-01 challenge (used by both webroot and standalone modes) requires port 80 to be reachable from the public internet at the challenge time, even if the final site will only serve HTTPS; DNS-01 avoids that requirement entirely by proving domain control through a TXT record instead.

Let's Encrypt Config Generator Use Cases

Issuing a first Let's Encrypt certificate for a new domain on Nginx or Apache
Setting up a wildcard certificate via DNS-01 for multiple subdomains
Looking up the exact certonly flags for a challenge type without digging through Certbot's docs

Common Mistakes

Running the standalone challenge while the web server is still bound to port 80, causing Certbot to fail with a port-in-use error.
Assuming DNS-01 works out of the box without installing a DNS provider plugin, then getting stuck at a manual TXT-record prompt that can't be automated for renewal.

Tips

Run the Certbot Renewal Config Generator right after issuing the certificate, rather than waiting until 90 days from now to find out renewal was never set up.

Let's Encrypt Config Generator