ACME: order a certificate when a domain's names change #295

Merged

jcoffey-dev merged 1 commits from fix/acme-renew-on-names-290 into main

2026-11-06 06:39:58 +00:00

jcoffey-dev commented

2026-11-05 15:57:47 +00:00

Owner

Fixes #290.

Editing Additional Hostnames on a domain already on ACME saved fine and ordered nothing. The new names waited for the next renewal, about 60 days out on a 90-day certificate.

What changes

Saving a domain queues an order when its names, its ACME provider or the domain name changed, not only when it switches to Automatic. The renewal task still decides: a valid certificate with exactly those names waits for its renewal date, so saving the same names in a different order does nothing. A provider change only orders straight away if it changes the names, for example an empty list going from the default hostnames to a wildcard.
A new renewal replaces the domain's queued one, whatever its state. Each run queues the next, so an extra task would be a second chain of renewals for good, and on a cluster both could order at once. This also covers switching to manual and back, the workaround given in the issue.
CAA and the _validation-persist record are published before the order when a save makes them out of date: a new provider, a renamed domain, switching to Automatic, or a name list going to or from empty, which decides policy=wildcard. Without this the CA refuses the order. A DNS task that renews afterwards may now have an empty record list, which publishes only the persist record.
The Dns01 check that the provider needs automatic DNS now also runs on these saves.

Tested

automation::automation_tests passes against Pebble (1 test, 90 s). New cases: adding a name issues a new certificate and leaves one queued renewal, reordering issues nothing, manual and back leaves one renewal, and a DNS-PERSIST-01 domain going from named hosts to the wildcard gets its certificate.
With each part disabled in turn, the suite fails: no trigger at acme.rs:852 (no new certificate), no replacement at acme.rs:864 (2 renewals), no republish at acme.rs:575 (no wildcard certificate).
New unit tests in mapping/domain.rs. Format, fork checks and cargo test --workspace --no-run are clean.

Not tested or not changed

Not run against a real CA.
A renewal running at the moment of the save can't be removed, so it can leave a second chain behind. The window is small and I haven't handled it.
The CAA part of the republish isn't exercised by a test, only the persist part. Changing provider adds the new CAA record next to the old one, because records for other accounts are kept. The new CA works, but the old account stays authorized until someone removes that record.
Renaming a domain republishes only these records, not the rest of its DNS. That was already the case.
The old certificate stays stored until it expires. For a name in both, the one that expires later is served, so the new one wins.

Fixes #290. Editing Additional Hostnames on a domain already on ACME saved fine and ordered nothing. The new names waited for the next renewal, about 60 days out on a 90-day certificate. **What changes** - Saving a domain queues an order when its names, its ACME provider or the domain name changed, not only when it switches to Automatic. The renewal task still decides: a valid certificate with exactly those names waits for its renewal date, so saving the same names in a different order does nothing. A provider change only orders straight away if it changes the names, for example an empty list going from the default hostnames to a wildcard. - A new renewal replaces the domain's queued one, whatever its state. Each run queues the next, so an extra task would be a second chain of renewals for good, and on a cluster both could order at once. This also covers switching to manual and back, the workaround given in the issue. - CAA and the `_validation-persist` record are published before the order when a save makes them out of date: a new provider, a renamed domain, switching to Automatic, or a name list going to or from empty, which decides `policy=wildcard`. Without this the CA refuses the order. A DNS task that renews afterwards may now have an empty record list, which publishes only the persist record. - The Dns01 check that the provider needs automatic DNS now also runs on these saves. **Tested** - `automation::automation_tests` passes against Pebble (1 test, 90 s). New cases: adding a name issues a new certificate and leaves one queued renewal, reordering issues nothing, manual and back leaves one renewal, and a DNS-PERSIST-01 domain going from named hosts to the wildcard gets its certificate. - With each part disabled in turn, the suite fails: no trigger at `acme.rs:852` (no new certificate), no replacement at `acme.rs:864` (2 renewals), no republish at `acme.rs:575` (no wildcard certificate). - New unit tests in `mapping/domain.rs`. Format, fork checks and `cargo test --workspace --no-run` are clean. **Not tested or not changed** - Not run against a real CA. - A renewal running at the moment of the save can't be removed, so it can leave a second chain behind. The window is small and I haven't handled it. - The CAA part of the republish isn't exercised by a test, only the persist part. Changing provider adds the new CAA record next to the old one, because records for other accounts are kept. The new CA works, but the old account stays authorized until someone removes that record. - Renaming a domain republishes only these records, not the rest of its DNS. That was already the case. - The old certificate stays stored until it expires. For a name in both, the one that expires later is served, so the new one wins.

jcoffey-dev added 1 commit 2026-11-05 15:57:47 +00:00

ACME: order a certificate when a domain's names change

ci / fork-checks (pull_request) Skipped

Details

ci / build (pull_request) Skipped

Details

github/ci (branch) GitHub Actions

Details

ci / github (pull_request) Successful in 10m46s

Details

69125b325d

Editing Additional Hostnames on a domain already on ACME saved fine and
ordered nothing, so the new names waited for the next renewal, about 60
days on a 90-day certificate. Saving now queues an order when the names,
the provider or the domain name change. A certificate that already has
those exact names just waits for its renewal date, so reordering the list
orders nothing.

Each renewal queues the next, so a second task would be a second chain of
renewals for good, and on a cluster both could order at once. A new
renewal now replaces the domain's queued one.

CAA and the DNS-PERSIST-01 record name the provider, and the persist
record says whether wildcards are allowed. When a save makes them out of
date they're published before the order, or the CA refuses it. A DNS task
that renews afterwards may now have an empty record list, which publishes
just the persist record.

Fixes #290

jcoffey-dev merged commit 4252ba840a into main

2026-11-06 06:39:58 +00:00

jcoffey-dev deleted branch fix/acme-renew-on-names-290

2026-11-06 06:39:58 +00:00

jcoffey-dev referenced this pull request

2026-11-06 06:57:58 +00:00

Version 27.1.0-rc.9 #298

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: inbuxa/inbuxa-server#295