Certbot: What the EFF ACME Client Actually Automates, and Where It Stops

The Problem Certbot Solves Is Certificate Plumbing, Not HTTPS Configuration

A web server needs a certificate from a certificate authority before browsers will treat its HTTPS responses as trustworthy, and the README frames the whole project around that one chore: getting and maintaining a certificate. Certbot is the client that talks to Let's Encrypt, the open CA the EFF launched with Mozilla and others, and pulls a domain-validated certificate down to the machine. The audience is narrow and specific. You run your own web server, you have root or administrator access to it, and you are willing to work on the command line. The README says this outright, and it also says the opposite case plainly: if you are on a hosted service without direct server access, Certbot may not be usable and you should ask your provider how to upload certificates or use Let's Encrypt-issued ones. That sentence is the most useful line in the README, because it pre-empts the most common support question. Certbot is not a certificate dashboard and not a hosted service. It is a program you install next to the thing it is securing.

Domain Validation Happens Through a Plugin, and the Plugin Decides the Blast Radius

To issue a certificate, the CA has to confirm you control the domain. Certbot supports several ways to prove that, and the choice is not cosmetic. The Apache and nginx plugins are the ones that can both obtain and install: they are listed as supporting Apache and nginx, and the feature list says configuration changes are logged and can be reverted. The webroot plugin takes a different route. It adds files to directories your web server already serves, so the CA can fetch them over HTTP. That means Certbot never touches your vhost configuration, which is the point: it works with server software that has no first-party plugin, and it works when you would rather edit config yourself. The standalone plugin goes further in the other direction. It runs its own simple web server to answer the challenge, which is why it needs the port free. On a machine already serving traffic on port 80, standalone will conflict with whatever is listening there. The README also notes that other server software is supported through third-party plugins, so the plugin list is extensible rather than closed. One detail worth flagging: the private key is generated locally on your system, which means the key material does not travel to the CA. Certbot can also revoke certificates.

Getting It Running: The Guide, the Flags, and the Root Requirement

Install steps depend on your operating system and web server, so follow the project's installation guide for your setup. You run Certbot on the server, you need root or administrator access in most cases, and you select a plugin. The plugin selection is expressed as flags in Certbot's documentation: --apache, --nginx, --webroot, and --standalone are the four first-party options named in the feature list, with -i or --installer used when you want to separate the installer from the authenticator. The feature list states that Certbot can optionally install an http to https redirect so the site effectively runs https only, and that it is fully automated. That combination is the reason people use the Apache and nginx plugins at all: with webroot you get a certificate file and nothing else, and with the server plugins you get the certificate plus the configuration edit plus the redirect, all in one command. Use the project's installation guide to get the exact package name for your distribution.

The Limits Are Structural: Hosted Hosting, Port Conflicts, and DV-Only Certificates

Certbot issues domain-validated certificates. If you need organization validation or extended validation, this is the wrong tool, and no plugin choice changes that. The standalone plugin needs to bind a port to answer the challenge, so it is a poor fit for a machine that is already serving HTTP on that port, which is most production web servers. The webroot plugin avoids the port problem but requires you to know which directory your server exposes and to point Certbot at it, and it will not install anything for you. The biggest limit is environmental. The README's own framing is that Certbot runs on your web server, not on your laptop, and that hosted customers without direct server access may not be able to use it. There is also a dependency on the ACME protocol itself. Certbot can talk to Let's Encrypt or to other ACME-compliant services. That is a real interoperability property, but it also means the tool's behaviour is bounded by what the CA's ACME endpoint allows, including rate limits and challenge types. Check your CA's own limits before assuming automation will cover a large batch of names.

Compared With a Configuration-Management or Proxy Approach

The realistic alternative for many teams is not another ACME client but a different layer entirely: terminating TLS at a reverse proxy or load balancer that handles certificate issuance and renewal itself, so individual web servers never hold a certificate. The difference in approach is where the certificate lives. Certbot installs a certificate onto the server it runs on, and its Apache and nginx plugins edit that server's configuration. A proxy-based setup centralizes the certificate on the proxy and leaves backend servers speaking plain HTTP behind it. If you have one server and no proxy, Certbot's model is simpler because there is no extra component. If you have many servers behind a proxy, running Certbot on each one duplicates work and spreads private keys across machines. That trade-off is the decision most teams actually face.

Maintenance, Releases, and What the Licence Field Does Not Tell You

The repository shows a steady release cadence: v5.7.0 in July 2026, v5.8.0 in September 2026 and v5.9.0 on 2026-10-29, with the last push to main later that same day. That rhythm matters for an ACME client because the protocol and the CA's policies move, and a client that stops tracking them eventually fails at issuance. The repository has a CHANGELOG.md for the detail, which is where you should look before upgrading a production server, since the Apache and nginx plugins modify configuration files and a behaviour change there is the kind of thing you want to read about first. On licensing, the repository metadata reports NOASSERTION, which means the automated classifier could not map the licence file to a known identifier. Do not treat that as permission or as a restriction. Read the actual licence file in the repository before you redistribute Certbot or bundle it into a product, and if you need a definitive answer, ask someone qualified rather than inferring from a metadata field. The repository also has a CODE_OF_CONDUCT.md, which concerns contribution, not use.

Editorial conclusion

Adopt Certbot if you run your own Apache or nginx server with root access and want certificate issuance plus optional http to https redirect handled by a command you can put in cron or a systemd timer. Do not adopt it if you are on shared hosting without shell access to the web server, since the README states Certbot is meant to be run directly on the server and points you back to your hosting provider for certificate upload instead. Before rolling it out, verify the exact plugin name for your server and confirm whether you want --installer or -i at all, because that flag is what separates obtaining a certificate from letting Certbot edit your vhost files.

Frequently asked questions

Official sources

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