Certbot 5.10.0: patch the webroot race, then check renewal permissions

קראו בעברית

12 November 2026 · PKI and certificate automation

Certbot 5.10.0, released on 10 November, fixes a webroot race that could change the wrong file’s owner or permissions when a less-privileged user can modify the webroot while Certbot runs. It also rejects invalid ARI renewal windows whose end is not later than their start. The official release notes describe both fixes.

Start with the local trust boundary

The webroot plugin proves domain control by placing a temporary challenge file in the website’s directory. The important condition in this fix is who can alter that directory during renewal. A public website alone does not establish that condition.

For a shared server, ask whether an application account, deployment process or tenant can change files in the renewal path while a more privileged Certbot process runs. Include parent directories in the review. This is a permissions review, not a reason to expose more of the filesystem or grant broad write access to make renewal work.

A focused operator checklist

1. Identify the actual renewal job. Record its authenticator, executable path and installed version. Check the scheduled job rather than assuming it uses the same Certbot installation as your shell.
2. Apply the fix through your supported installation route. Upstream 5.10.0 contains the fix. If your distribution backports fixes, use its package advisory to establish coverage instead of comparing only the version number.
3. Review access to the challenge path. Document which accounts can write there and whether they should. Make any permissions change deliberately, with a renewal test, rather than recursively changing ownership across the website.
4. Test the configured renewal workflow. The documented certbot renew --dry-run is useful, but review hooks and any custom ACME server first. Use the scheduled executable and its relevant configuration options. Pre/post hooks run by default, and webserver reloads may occur; deploy hooks normally require explicit enabling.
5. Watch the next scheduled run. Check renewal errors and certificate expiry monitoring. A successful dry run checks renewal functionality, not whether permissions are secure or whether the race is fixed. Check that the timer, service account and deployment hooks work together.

Keep the test and the claim narrow

Certbot normally uses Let’s Encrypt staging for a dry run; a configured --server can change that. Consult the Certbot user guide before testing a custom setup. Do not weaken certificate verification to get a green result.

The two fixes address different parts of automation: local file handling and validation of a suggested renewal schedule. This article does not establish exploitation of your server or report a hands-on reproduction. Its practical recommendation is to patch the client and verify the permissions and scheduled workflow around it.

Checked 12 November 2026. Sources: upstream release notes, PyPI release record and Certbot documentation. Publication date is separate from the 10 November release date.