v2.48.6 (the renewal sweep asks about a name itself, and two of its recovery paths say what happened)
A patch release, all of it in the renewal sweep apart from the base image. The sweep now checks a certificate name before it builds a path from it, renews a Sectigo certificate with prevalidated authorizations that no settings entry names, and stops reporting a re-registration that was never saved.
Read this before upgrading
Nothing needs to change on your side. No route, setting or file format differs from 2.48.5, and the API contract stays at 2.44.
Security
- The renewal sweep asks about a name before it builds a path from it (#1224).
check_renewalsread the certificate names from the settings and relied on their having been checked when the settings were saved. A name that arrived by a restored archive could reach it without that check. The sweep now refuses a name that is not a usable certificate name and counts it as invalid, so it no longer depends on one layer alone. A test restores an archive whose settings name paths, and checks that the listing, the dashboard, the inventory, the metrics, the certificate routes, the sweep and backup creation open, list, rename or remove nothing outside the certificate root.
Fixed
- A disk-only Sectigo certificate with prevalidated authorizations is renewed (#1229, contributed by QuentinBtd). For a certificate on disk that no settings entry names, the sweep checked for DNS credentials before renewing it. A certificate issued with Sectigo's prevalidated authorizations needs none, so it was reported as unmanaged at every sweep and never renewed. The check now states what the renewal path states:
prevalidatedneeds nothing from DNS, and is refused only for a CA other than Sectigo. - A re-registration that was not saved is no longer reported as done (#1230, contributed by QuentinBtd). After renewing a disk-only certificate, the sweep writes it back to the settings. The settings save reports a failure by returning false, never by raising, so a failed save was counted as re-registered, logged as such and audited as a success. It is now logged as a failure and not counted.
Changed
- The base image is pinned to the digest its tag points at today (#1223, #403).
python:3.12-slim-trixie, in both stages of the Dockerfile. Trivy on the published 2.48.5 and on the same Dockerfile rebuilt on the new digest: 257 findings against 256, one fewer and none new.
How it was checked
- The end-to-end bench with a private CA, rebuilt from
mainat7c85e9d. The scheduler's real renewal job renewed the 10 certificates on the bench, 10 of 10, each with a new serial. A new certificate was issued from the private CA over HTTP-01, and the same job renewed it once it was due. - The new tests against the code before the fixes. Each test added in #1229 and #1230 passes on its branch and fails on the code before it, in the case it is about.
- The release gate runs on the release commit: the suite, the browser tests, and real certificates from Let's Encrypt staging (mandatory here, since the release changes
modules/core/certificates.py).
Not verified
- A real Sectigo certificate. The prevalidated path is covered by tests with the CA mocked; no Sectigo account was used.
- A failed settings save on a running instance. The re-registration failure is covered by a test that makes the save return false; it was not reproduced on a live instance.