fabriziosalmi/certmate v2.48.1

v2.48.1 (DNS aliases on Akamai Edge DNS, one log record per line, and health checks that keep their reasons)

on GitHub

v2.48.1 (DNS aliases on Akamai Edge DNS, one log record per line, and health checks that keep their reasons)

A patch release. A certificate with a DNS alias on Akamai Edge DNS can be issued; until now it could not. In the plain log format each record stays on one line. The public health routes still say that a check failed, and give the reason only to a caller with credentials. Create refuses a domain with a non-ASCII letter in its top-level domain. The API contract stays at 2.42: no field changes shape.

Read this before upgrading

If you use a DNS alias with Akamai Edge DNS

The alias hook for Edge DNS (domain_alias with dns_provider: edgedns, added in v2.4.6) used paths that the Edge DNS API does not have. Single record sets live at /config-dns/v2/zones/{zone}/names/{name}/types/{type}, as in Akamai's API reference and in certbot-plugin-edgedns. As a result, issuing through an Edge DNS alias failed when the TXT record was created. Separately, the hook also wrote the whole record set with only its own value. A wildcard with its apex (*.example.com and example.com) needs two values under one name, so one of the two challenges could not pass.

The hook now adds and removes only its own value, at the documented paths. If an Edge DNS alias certificate failed for you, issue it again after upgrading.

This was checked against a stand-in that accepts only the documented paths, not against a live Akamai account (see "Not verified").

If you read /health or /health/ready without credentials

Both routes are public on purpose: a load balancer and a readiness probe carry no token. They still report the state to anyone:

• certbot: failed and status: degraded;
• 503 from readiness;
• the scheduler state.

The reason is now returned only to a request that carries credentials (a session or an API token). That reason is the text in certbot_error and scheduler_error, which is the tail of certbot's output or the scheduler's exception. Anyone else gets a fixed sentence pointing at the server log, where the reason is written at CRITICAL. The fields keep their names and types, so nothing that reads them breaks. A monitor that wants the reason sends its token. While setup is not complete, the reason is withheld from everyone.

If you use the plain log format (CERTMATE_LOG_JSON=false)

Each record is one line. A line break inside a logged value is written as \n, and the lines of a traceback are indented, so only the first line of a record starts at the left margin. A log parser that splits records on lines starting with a timestamp keeps working; one that expected tracebacks at the left margin sees them indented. The default JSON format does not change.

Fixed

• Akamai Edge DNS aliases (#1144), above.
• Create accepted a top-level domain with a non-ASCII letter (#1143). For example, example.cοm with a Greek omicron. Every later route refuses that name. Create made the certificate's directory, certbot refused the name, and the empty directory stayed: absent from the list and not deletable through the API. A name written in Punycode is unaffected.
• POST /api/notifications/test answered an unexpected server error with the exception's text. It now answers Notification test failed and logs the detail. A delivery failure, which is what the test is for, is still returned as before.

Changed

• Public health routes keep the reason for credentials (#1150), above.
• Plain log format, one record per line (#1150), above. The same formatter writes the audit log's file.

Documentation

• When a certificate renews is now stated the same way everywhere (#1145): 30 days before expiry by default, earlier for a certificate that lives under 60 days. This covers the README, the Docker Hub page, the architecture page and the guide in five languages. The renewal sweeps run between 01:00 and 03:00 (server certificates) and between 02:00 and 04:00 (client certificates), not "at 3 AM".
• The Docker Hub page said "23 DNS Providers". It now points at the list, as the README does, and the test that keeps the count in one place reads that page too.
• The v2.42.0 notes dated the Akamai Edge DNS wait change to v2.40.0; it shipped in v2.41.0 (#1141).

How it was checked

• Edge DNS: the real hook against a stand-in that knows only Akamai's documented paths, answers 404 to any other, and returns TXT data quoted as Edge DNS does. On v2.48.0, 5 of the 7 tests fail when the record is created. Four deliberate breakages are each caught:
  • the old path;
  • writing only one value;
  • deleting the whole set;
  • comparing without the quotes.
• Plain log format: the application itself, run with CERTMATE_LOG_JSON=false, with a create request whose SAN contains a line break. The value stayed on its record's line, including with the call-site scrubbing removed, so the formatter alone holds it.
• Health routes: the real AuthManager, tried with a real API key, a wrong token, setup mode, and an identity that is not a user record.
• Deliberate breakages: seven mutations of the log and health changes and six of the domain and path checks, each caught by the test meant for it.
• The release gate runs on the release commit: the suite, the browser tests, and real certificates from Let's Encrypt staging.

Not verified

• Edge DNS against a live Akamai account. The paths and request bodies come from Akamai's API reference and from the published plugin, and the stand-in enforces them, but no request went to Akamai. If you use Edge DNS with an alias, a report from a real zone would close that.