Certbot

What Certbot actually is

Certbot is the Electronic Frontier Foundation's ACME client: a command-line tool that obtains TLS certificates from Let's Encrypt (or any other CA that speaks ACME) and installs them into your web server, then keeps renewing them on a schedule so HTTPS does not expire on you. It began life as the original Let's Encrypt client — the code was always primarily developed by EFF and contributors, hosted under the Let's Encrypt organization until the May 2016 rename moved it to EFF proper — and it remains the most widely used client for people running their own servers. The repository dates to November 2014; the Apache 2.0 license file is copyright the Electronic Frontier Foundation.

The working parts are simple. On a server with root access, Certbot talks to the CA over the ACME protocol, proves you control a domain, receives a certificate, and writes it to disk. The "certbot --apache" and "--nginx" plugins parse your server configuration and edit it to serve HTTPS and redirect HTTP; standalone mode runs its own temporary listener; webroot mode drops challenge files into an existing web directory. For wildcard certificates — issued by Let's Encrypt since March 2018 — DNS-01 validation is required, and Certbot has first-party plugins for a long list of DNS providers (Cloudflare, DigitalOcean, Google, Linode, DNSimple, DNS Made Easy, RFC2136, and more), plus community plugins for others. Renewal is handled by a twice-daily systemd timer or cron entry that renews anything within 30 days of expiry.

Two properties make it the default recommendation in most guides. It works with any ACME CA, not just Let's Encrypt, so a CA change is a flag rather than a migration. And the interactive instruction generator on certbot.eff.org produces exact commands for your combination of software and OS — Apache, Nginx, HAProxy, Plesk, Bitnami, FreeBSD, OpenBSD, macOS, and Linux via snap or pip. That tool lowers the entry barrier more than any amount of documentation does.

Pricing: what you really pay

Certbot is free and open source (Apache 2.0), and so are the certificates from Let's Encrypt. There is no pro tier, no paid plugin, no usage cap. The EFF funds development as part of its mission to encrypt the web and asks for donations rather than charging users — the donate link sits in the header of certbot.eff.org.

The costs are the usual ones for free infrastructure tooling: your time and your risk management. Installation is a package or snap away, but understanding challenge types, chain files, and renewal hooks takes an afternoon. More importantly, nobody is contractually accountable when renewal fails — and renewal failures are silent by nature. Certificate expiry incidents remain one of the most common self-inflicted outages in the industry, and while Certbot makes them rare, it does not make them impossible. We consider monitoring certificate expiry (a simple external check) mandatory for anything that matters, whether you use Certbot or any other client.

Compared with commercial certificate lifecycle management platforms that charge per certificate per year, Certbot plus Let's Encrypt is the right answer for a very large share of the web. Where those platforms earn their keep is fleet-scale policy, approval workflows, and support — needs most single-server operators and small fleets simply do not have.

Performance & infrastructure

There is no infrastructure to review: Certbot is a client that runs on your own server. It is written in Python, installs as a snap or via pip and OS packages, and its runtime footprint is negligible — it runs, does its work, and exits. The performance question that matters is operational: how reliably renewal happens and how changes to your server config are handled.

On renewal, the design is sound — a timer renews certificates well before expiry, and post-renewal hooks reload your web server. On config handling, the Apache and Nginx plugins are clever but conservative: they will refuse to modify configurations they cannot parse cleanly, falling back to manual installation rather than breaking your site. That behavior annoys people in the moment and is the correct trade-off in our view. The plugin architecture also keeps the core small: DNS plugins are separate packages, so you install only what you need.

The certificate side of the equation deserves a note. Let's Encrypt issues 90-day certificates by design — short lifetimes limit the damage of key compromise and force automation, which is exactly the workflow Certbot is built for. OCSP stapling, chain selection, and key type (RSA or ECDSA) are all configurable. For multi-server or container fleets, run Certbot where the challenge can be answered (or use DNS-01) and distribute the results, or look at clients designed for central issuance; Certbot's sweet spot is the single-server-to-small-fleet case. If you are choosing the hardware to run this on, our benchmarks cover the hosts we trust for small always-on servers.

Where it falls short

Certbot assumes a traditional server with root access and a supported web server layout. In containerized or serverless environments, on platforms where you cannot open port 80 or 443, or behind certain control panels, the standard plugins do not apply and you end up in webroot or DNS-01 mode with manual wiring. It is a Unix tool in a world increasingly full of orchestrators; alternatives like acme.sh (pure shell, extremely portable), Caddy (certificates built into the web server), or Traefik/ingress controllers handle some of these shapes better.

Second, failure modes are quiet. A DNS plugin whose API token expired, a vhost the parser no longer understands, a port-80 redirect that blocks HTTP-01 — each of these fails at renewal time, weeks after installation, unless something is watching. Certbot logs, and hooks can alert, but the burden is on you to wire that up. Third, the project's pace is deliberate: it is a mature, mission-funded tool, not a commercial product with a roadmap you can buy influence over. Bug fixes and plugin updates happen on open-source time.

Finally, scope: Certbot manages certificates and nothing else. It will not tell you when one is about to expire outside its own logs. No TLS configuration hardening beyond sane defaults, no monitoring, no inventory. That is a virtue for a focused tool, but it means the "certificate management" problem is only solved when you add the observability around it.

Who should pick this

We pick Certbot for anyone running their own Linux server who wants free certificates with the least possible ceremony: sysadmins maintaining Apache or Nginx hosts, small agencies with a fleet of client sites, homelab setups, and anyone following a distribution's official HTTPS documentation, which almost always names Certbot. The interactive instruction tool means a beginner can get a correct result without understanding ACME, and the same tool supports DNS-01 wildcards for people who do. It is also the right teaching tool: understanding how HTTPS automation actually works — challenge types, validation, renewal timing, chain files — is easier when the tool's behavior is explicit and documented, and Certbot is both. When we explain certificate automation to newcomers, this is the client we demonstrate.

A comparison we are asked for often: Certbot versus acme.sh. Both are free and both work; acme.sh is a single shell script with extraordinary portability and a lighter dependency footprint, while Certbot is a structured Python project with installer plugins that edit server configs for you and a long track record of conservative behavior around your files. We use and recommend both — Certbot where the Apache and Nginx plugins save real work, acme.sh where the environment is unusual or minimal.

We would look elsewhere for Kubernetes ingress automation (use cert-manager), for environments where you cannot run a root-level daemon (consider acme.sh or DNS-01 from outside), and for organizations that need certificate lifecycle management with policy and support contracts. And for new single-server deployments, honestly, a web server with ACME built in — see our take on Caddy — removes even Certbot's step from the process.

Key takeaways

• EFF's free Apache 2.0 ACME client (2014 code origins, renamed Certbot in May 2016); works with any ACME CA, not just Let's Encrypt.
• Automates issuance, installation, and renewal for Apache, Nginx, HAProxy, Plesk, standalone, and webroot modes.
• Wildcard certificates via DNS-01 with first-party plugins for Cloudflare, Google, Linode, DigitalOcean, and many more.
• Zero license cost; real costs are setup time and monitoring, because renewal failures are silent.
• Outstanding onboarding via the interactive instruction generator; huge community, extensive docs.
• Best fit: self-managed Linux web servers; poor fit: container/serverless fleets or anyone needing contractual certificate lifecycle management.

Sources

• https://certbot.eff.org/
• https://github.com/certbot/certbot
• https://raw.githubusercontent.com/certbot/certbot/master/LICENSE.txt
• https://eff.org/deeplinks/2016/05/announcing-certbot-new-tls-robot
• https://eff.org/deeplinks/2016/03/new-name-and-roadmap-lets-encrypt-client
• https://certbot.eff.org/faq
• https://github.com/certbot/certbot/blob/master/certbot/CHANGELOG.md