github fabriziosalmi/certmate v2.55.0
v2.55.0 (the renewal checks survive the clocks going back, and two certificates for one domain)

3 hours ago

v2.55.0 (the renewal checks survive the clocks going back, and two certificates for one domain)

A fix that cannot wait, one feature built in steps, and two more fixes.

  • Fix: CertMate starts again after the night the clocks go back (#1372). An instance in a time zone that repeats 02:00 to 03:00 when the clocks go back, such as Europe/Rome or Europe/Zagreb (a container started with such a TZ, or the Linux installer on a host set to one), stopped on 25 October 2026 and would not start again: the renewal check's next run never left that hour, because APScheduler 3.11.3 loses the fold when it adds the jitter (agronholm/apscheduler#1183), and the scheduler read the stored job before replacing it. The two renewal checks are scheduled in UTC now, and the jobs are replaced before the scheduler starts, so an affected instance starts again on upgrade with its data as it is. Exposed since v2.26.3; the published image sets no TZ, so a container left at its default ran in UTC and was not affected.
  • A certificate can be named apart from its domain, so one domain can hold two (#854, #1367, #1368, #1369). A second certificate for example.com, from another CA such as a private one, gets a name of its own, internal.example.com: Name in the create form's Advanced Options, name on POST /api/certificates/create, --name in the CLI, name= in the SDK and name in the MCP server's create tool. It is issued for example.com, its host, and every later action (renew, reissue, download, deploy, delete) takes the name. A name has the shape of a DNS name, is not a wildcard unless it is the wildcard certificate's own domain, and an IP certificate takes none. Verified on Let's Encrypt staging: two certificates for one host, the one named apart issued, renewed and reissued for the host, and deleting it left the other as it was. See Create a certificate.
  • Every answer says where a certificate is served (#1360, #1364, #1365, #1366). Certificate answers carry host: the address of an IP certificate, the host of a certificate named apart, and its name otherwise. Deploy hooks get CERTMATE_HOST beside CERTMATE_DOMAIN, webhook targets {{host}}, and every event about a server certificate host. The deployment check, discovery, CT-log monitoring, domain health and domain registration look at the host. The SDK, the CLI and the MCP server read it.
  • A key restricted to domains is judged on a certificate's name too (#1363, #1367, #1370). A certificate is a key's when its scope covers its name and every name it covers: its host, its SANs and the DNS names in it. The dashboard's batch download, the cache statistics and the metrics read only the names covered, so a key scoped to a host was given a certificate named outside its scope; they judge the name now, as every route on a certificate did. A certificate is issued for its host, and a CSR must cover it.
  • Fix: an IP certificate is looked for at its address (#1359). The deployment check probed a host called ip-203-0-113-5, the dashboard's browser check fetched it, and discovery probed it. They use the address now; the browser check also follows a deployment_host, which it ignored. CT-log monitoring and domain health leave an IP certificate out.
  • Fix: discovery calls a served certificate issued only when CertMate holds it (#1358). A sweep decided from the host alone, so a certificate from another CA, still served after a renewal that was never deployed, read as one CertMate issued. Its fingerprint decides now: issued, imported or probed.
  • Docs: the README and the ACME server page say what the server certifies, and when a CA run apart fits better (#1361); the webhook target section shows the body it sends (#1357).

The renewal checks run in UTC. Server certificates are checked between 02:00 and 03:00 UTC and client certificates between 03:00 and 04:00 UTC, whatever the instance's time zone; on a host in Rome that is 03:00 to 04:00 in winter. The other daily jobs keep the instance's zone, and a deploy window still holds a deploy until it opens.

Backups. An archive that holds a certificate named apart from its domain must not be restored into an older version: an older version ignores host, so it would ask the CA for the name on the next reissue, and check the name instead of the host. See After a downgrade.

Under the hood: the real-certificate release gate gains a test of two certificates for one host on Let's Encrypt staging. certmate-sdk and certmate-cli 0.1.6, on PyPI since 26 October, take name and read host.

The API contract moves to 2.61 (MINOR): 2.59 adds host to every certificate answer, the create answer and a create job's result; 2.60 adds host to every event about a server certificate, CERTMATE_HOST to deploy hooks and {{host}} to webhook targets; 2.61 lets POST /api/certificates/create take name.

Don't miss a new certmate release

NewReleases is sending notifications on new releases.