Certbot: ACME Certificate Automation for Your Own Web Server

The certificate chore Certbot was built to remove

Obtaining a TLS certificate by hand involves generating a key pair, producing a certificate signing request, proving to a certificate authority that you control the domain, downloading the signed certificate, and wiring it into the web server's configuration. Then the certificate expires and you do it again. Certbot exists to collapse that sequence into a command, and to keep it collapsed on a schedule.

The README frames the audience narrowly: Certbot is meant to be run directly on your web server on the command line, not on your personal computer. That single sentence rules out a large class of users. If you are on shared hosting and have no shell on the machine that terminates TLS, the README points you at your hosting provider's documentation for uploading certificates instead. Certbot is for people who own the box.

It is also for people who want a certificate authority that does not charge. The README states plainly that using Certbot and Let's Encrypt is free. Certbot itself is the client; Let's Encrypt is the CA. That distinction matters for anyone confused about what they are installing.

How Certbot proves domain control and where the key lives

Certbot speaks the ACME protocol, specified in RFC 8555, to a certificate authority. The README says it can talk to the Let's Encrypt CA or optionally to other ACME compliant services, so the CA endpoint is a choice rather than a fixed part of the design.

Validation is where the architecture becomes visible. The README lists the supported methods: Apache 2.4+, nginx 0.8.48+, webroot, standalone, and third party plugins. The webroot plugin adds files to webroot directories in order to prove control of domains. The standalone plugin runs its own simple webserver to prove you control a domain. The Apache and nginx plugins go further and reconfigure the running server, which is why the README can advertise that Certbot optionally installs an http to https redirect.

One design decision deserves emphasis: the private key is generated locally on your system. The key never leaves the machine, and only the public half goes to the CA in the certificate signing request. Certbot supports ECDSA (default) and RSA certificate private keys, so the key type is a real choice rather than an accident of defaults.

The plugin split is the practical core of the project. The repository carries certbot-apache, certbot-nginx, and a row of DNS plugins for Cloudflare, DigitalOcean, DNSimple, DNS Made Easy, Gehirn, Google, Linode, LuaDNS, NSONE, OVH, RFC 2136, Route 53, and Sakura Cloud. If your DNS provider is not on that list, the DNS challenge route is closed unless a third party plugin covers it.

Installing Certbot and issuing a first certificate with the nginx plugin

The README does not give package manager commands. It says the best way to get started is the interactive guide at certbot.eff.org, which generates instructions based on your configuration settings, and it notes that in most cases you will need root or administrator access to your web server. So the honest answer to how to install Certbot is: go to the guide, pick your operating system and server, and run what it prints. The commands the guide produces are the ones to use, and the README does not document any of them itself.

What the README does document is the plugin model that determines which package you end up installing. There is a plugin for nginx, a plugin for Apache, and the webroot and standalone methods that ship with the client. The DNS plugins live in their own directories, one per provider, named after the provider: certbot-dns-cloudflare, certbot-dns-google, certbot-dns-route53, and the rest of the list in the repository root.

Once the client and the relevant plugin are on the machine, the first real use is a single invocation naming the domains you want covered. The README describes the outcome rather than the syntax: Certbot fetches a certificate from Let's Encrypt and deploys it to a web server, and it can optionally install an http to https redirect so the site effectively runs https only. With the nginx or Apache plugin, that deployment means Certbot edits the server configuration for you. With webroot or standalone, it does not, and you point the server at the issued files yourself.

The README notes that configuration changes are logged and can be reverted, so a plugin-driven edit is not a one-way door. That property is worth checking before you let Certbot touch a production server block, and it is the reason the plugin approach is defensible at all.

Renewal is the part that decides whether Certbot is worth it

A certificate that is issued once and forgotten is worse than no automation at all, because it fails silently at an unpredictable hour. Certbot's value is in the second half of its lifecycle, and the README's feature list is explicit that it is fully automated.

Renewal is the subcommand people search for most often, and the README treats it as part of the same automated flow rather than a separate product. On a normal installation it is driven by a systemd timer or cron job that the package sets up, and it is designed to be safe to run on a schedule: certificates that are not near expiry are skipped. That is the mechanism, and it is also the failure mode. If the timer is disabled, if the ACME challenge path stops working because someone changed a server block, or if a DNS record used for a DNS-01 challenge was edited by hand, renewal fails and nothing announces it except a log line and eventually an expired certificate in a browser.

The README does not document alerting, monitoring, or notification of failed renewals. That gap is not a reason to avoid Certbot, but it is a reason to test renewal deliberately rather than assume it. The README does not document a dry-run rehearsal either, so treat the first renewal cycle after any configuration change as something to watch rather than something to trust.

Where Certbot is the wrong tool

The clearest boundary is the one the README draws itself: hosted services without direct server access. If you cannot run commands on the machine that serves the site, Certbot cannot help you, and the README says to check with your hosting provider instead.

A second boundary is the challenge method. If your service cannot answer an HTTP request for the domain, and your DNS provider is not among the plugins in the repository, you are left implementing a plugin or moving certificate issuance elsewhere. The plugin list is long but it is finite, and the README's phrase other server software via third party plugins is doing a lot of work: third party means not maintained by this project.

A third boundary is scope. The README says Certbot can get domain-validated (DV) certificates. That is the whole category. If you need organization validation or extended validation, where a CA checks your legal identity, Certbot is not the tool, because Let's Encrypt does not issue those.

Finally, consider whether you want a tool editing your web server configuration at all. The nginx and Apache plugins are convenient precisely because they write into your config files. On a server whose configuration is generated by a deployment system, that convenience becomes a conflict: the next deploy may overwrite what Certbot inserted. In that situation the webroot or DNS plugin plus a manual config entry is the more stable arrangement, even though it is more work up front.

Certbot against acme.sh and other ACME clients

The obvious alternative is acme.sh, a shell-based ACME client. The difference in approach is not cosmetic. Certbot is a Python application with per-server plugins that integrate with Apache and nginx configuration, installed through your distribution's package manager or as a snap. acme.sh is a shell script with no runtime dependency on a Python interpreter and no server-configuration plugins, leaving the web server config entirely to you.

That makes acme.sh attractive on minimal systems, on appliances where installing Python packages is awkward, and for anyone who wants issuance decoupled from server configuration. Certbot's counter-argument is the integration: the nginx and Apache plugins, the logged and revertible configuration changes, and the distribution packaging mean that on a conventional Debian or Ubuntu web server the whole job is one install and one command.

A second alternative worth naming is using the ACME protocol directly or through a library, since the repository ships the acme package as a separate top-level directory. That path is for people building certificate management into their own software, not for people who want a certificate on a web server today.

The choice usually comes down to whether you want a tool that knows about nginx, or a tool that knows only about ACME.

Maintenance, licensing, and the cost of staying current

The repository is not archived, and the last push was on 2026-09-09. Releases are frequent: v5.6.0 on 2026-05-11, v5.7.0 on 2026-07-21, and v5.8.0 on 2026-09-01. For an operator, that cadence is a genuine maintenance commitment, because the ACME ecosystem moves: CA policies change, challenge validation tightens, and a client that stops tracking those changes stops renewing.

Upgrade cost is low if you installed through your distribution or as a snap, since both channels deliver new versions through their own mechanisms. It is higher if you pinned a version or vendored the acme library into another project, because then you own the upgrade. The repository's newsfragments directory and towncrier configuration indicate that changes are recorded as fragments before release, which is useful when you need to know whether an upgrade affects your plugin.

The licence is the awkward part. The repository metadata reports NOASSERTION rather than a recognised SPDX identifier, and the top-level LICENSE.txt is the authoritative file. Certbot is an EFF project, and the EFF's Public Projects Code of Conduct governs contribution, but that is a separate document from the licence. If you are redistributing Certbot, bundling it into a product, or shipping a modified plugin, read LICENSE.txt yourself and get your own advice. This article is not legal advice and the metadata alone does not tell you the terms.

Editorial conclusion

Adopt Certbot if you control the shell of the machine serving your site and want certificate issuance and renewal handled by a single command with a documented revert path. Do not adopt it if your site lives behind a hosting panel with no root access, or if you need certificates for services that cannot answer an HTTP challenge and have no DNS plugin for your provider. Before rolling it out, confirm your server software version against the supported list (Apache 2.4+, nginx 0.8.48+), decide which plugin matches your setup, and check whether a DNS plugin exists for your provider in the repository's plugin directories.

Frequently asked questions

Official sources

1. certbot/certbot on GitHub
2. Issues
3. README
4. Releases