v2.44.0 (CA accounts you can manage, and the email the CA is told)
CA accounts get a real place in the web interface, and the email you type into one is now the email the CA is given. The API contract stays at 2.32: the one new route belongs to the web interface, not to the documented API.
Thanks to @QuentinBtd for the feature this release is built around.
Read this before upgrading
New certificates register with the CA account's email
Until now certbot was always given the global email setting, whichever CA account issued the certificate: the email typed into a CA account was stored and never used. A new issuance now uses the selected CA account's email, and falls back to the global email only when that account has none.
- Two accounts on the same CA with different emails now register two different contacts.
- An ACME account that certbot already registered is not changed. To change its contact, use
certbot update_account. - Nothing to do if you have one account per CA and the same email everywhere.
Settings files are cleaned once, on the first start
When a CA had both a legacy flat entry (email, eab_kid, eab_hmac, …) and an accounts block, CertMate read only the accounts, so the flat keys were a second copy of an account's data that nothing used and nothing updated. Rotating an EAB secret left the old one in settings.json and in every backup taken since.
On the first start of this release those unused copies are removed. What CertMate uses does not change. A _migration backup is taken first, as for any settings migration. From now on converting a CA to accounts moves the flat keys instead of copying them, and a settings write that still uses the flat shape is applied to the account CertMate uses by default instead of being accepted and ignored.
New account names are restricted
A new CA account name is limited to letters, digits, ., _ and - (1 to 64 characters, starting with a letter or digit). Accounts that already exist keep their names and stay editable and deletable.
New
- CA accounts in Settings. Settings → Certificate Authority (CA) Providers lists every account, with Add CA Account, Edit, Delete, Default for this CA and Make global default. Secrets are masked and preserved when you edit an account without retyping them.
- The issuance form offers only what can issue. The CA list shows the authorities that are configured and usable, and the account list follows the selected CA. With none usable, the form says so and points at Settings instead of sending a request that would be refused.
- Safeguards on delete. The global default account cannot be deleted, and neither can an account a certificate was issued with.
- Audit trail. Creating, updating and deleting a CA account is recorded with the user and the
provider:account, and the names of the fields that changed, never their values.
Fixed
- The account email reaches the CA (see above).
- Secret copies beside
accountsare gone (see above). - PyJWT is locked at 2.15.1, fixing GHSA-42vr-xj54-vc7v (a denial of service in parsing a token before it is verified). PyJWT comes in as a dependency of other packages; CertMate does not call it directly.
- The dependency lock is regenerated: SQLAlchemy 2.0 → 2.1 (used only for the scheduler's persistent job store, which was checked across a restart), Werkzeug 3.1.9 and 18 smaller updates.
How it was checked
- A real certificate. Issued from Let's Encrypt staging through Cloudflare DNS-01 under a CA account whose email differs from the global one, then the registration request certbot sent was read back: it carries the account's email. With the old behaviour restored, the same test fails. This test is now part of the release gate.
- In a browser, from a settings file with legacy flat credentials: adding an account, rotating a secret and deleting an account leave one copy on disk, and neither the old secret nor any secret appears in the audit log.
- The lock was installed into an empty environment:
certbot --versionruns and the full suite passes.