[SoulInfernoDE]

Description

_{Screenshots of the SynoCommunity build (English, dark design); click for full size.}

Tested on a real DiskStation with DSM 7.4 (IONOS SSL, 2-step verification enforced for all administrators) and on Virtual DSM 7.2.2 — details below.

New package Advanced ACME (advanced-acme, noarch, DSM 7): automatic SSL certificates for DSM from IONOS SSL (ACME with External Account Binding, 180-day certificates), Let's Encrypt, ZeroSSL or any ACME server. DNS-01 validation for 200+ DNS providers through acme.sh (the NAS does not need to be reachable from the internet), automatic renewal and installation into the DSM certificate manager. Guided web interface in 20 languages with a light and an optional dark design, uninstall wizard and Package Center texts in all DSM languages.

Upstream: https://github.com/SoulInfernoDE/synology-advanced-acme (GPL-3.0, release v0.1.11)

What it offers

• Fully localized: the web interface is available in all 20 DSM interface languages and follows the DSM language (or can be set per browser). Package Center description and uninstall wizard come in every DSM language (for Thai see the note below). All texts live in locale catalogs with English as base and fallback.
• Guided setup, no command line needed: an assistant walks through CA, account (including External Account Binding), DNS provider, domains and the target certificate in DSM. API keys are checked right away, and log output of failed jobs is translated into plain explanations.
• IONOS SSL as a first-class CA: EAB, 180-day certificates, the IONOS DNS API, and the longer certificate polling IONOS needs. Let's Encrypt, ZeroSSL and any other ACME server work the same way.
• Clean DSM integration: certificates land in the normal DSM certificate manager. Replacing an existing certificate keeps all its service assignments, including reverse proxy entries. DSM itself is not modified, and the package runs as its own unprivileged user.
• Works where all administrators must use 2-step verification: through the optional DSM task described below.
• Transparent: DSM notifications for issued certificates and failures, a history of every step that touches DSM (account, task, installations), the service log, and an acme.sh console plus advanced-acme CLI for experts. Certificates created there are managed and renewed like the others.
• Tested: an end-to-end test (102 checks) runs the complete flow against Pebble with EAB and 180-day certificates and mocks of the DSM Web API and the IONOS DNS API.

Packages

• cross/acme.sh: official acme.sh 3.1.6 release, with one patch: after finalizing an order acme.sh polls for the certificate only 30 × 2 s when the CA sends no Retry-After header; IONOS (Sectigo) often needs several minutes. The patch keeps the loop but uses the backoff acme.sh uses elsewhere (about 9 minutes in total) and makes the number of polls adjustable (MAX_CERT_RETRY_TIMES, default unchanged).
• cross/advanced-acme: the program files (bash backend, CGI, web interface), staged by the project's build.sh --stage next to the acme.sh from cross/acme.sh.
• spk/advanced-acme: SERVICE_USER = auto (sc-advanced-acme), service through the generic start-stop-status, DSM desktop application (DSM_UI_DIR = ui), /usr/local/bin/advanced-acme, uninstall wizard with wizard_delete_data.

Points worth a look

• No runtime downloads of code: the interface of the upstream package can optionally install newer acme.sh releases. This build turns that off (ACME_UPDATES=0); acme.sh is updated only with the package.
• Installing into DSM: DSM 7 does not allow certificate-config for community packages, so certificates are imported through the DSM Web API. The user chooses one of three ways, each only after explicit consent:
  1. an existing DSM account;
  2. a dedicated account advanced-acme, created with a one-time administrator sign-in and a random password (the administrator's password is not stored; the account is deleted again with "delete data" on uninstall);
  3. for NAS that enforce 2-step verification for all administrators: a root task "Advanced ACME" in the Task Scheduler, created with a one-time administrator sign-in. Its script is stored in the task itself, runs no package files, only reads checked requests from the package's data folder, imports with synowebapi and deletes itself when the package is uninstalled.
• Overlap with dnsacme: both issue certificates via DNS-01. Advanced ACME adds IONOS SSL with EAB and the IONOS DNS API, the DNS providers of acme.sh, and the root task for NAS with enforced 2-step verification. If you prefer to keep a single ACME package, I'm happy to discuss.
• SPK_CONFLICT = AdvancedACME: the upstream release package has the same DSM task; only one of them can be installed.
• The Thai description (DESCRIPTION_THA) is included but not written to INFO, because LANGUAGES in mk/spksrc.common.mk has no tha.

Build: make -C spk/advanced-acme TCVERSION=7.1 ARCH=noarch in the spksrc container. make arch-noarch-7.1 stops in the pre-check ("SRM < 3.0" with an empty TCVERSION from REQUIRED_MIN_SRM); I could not tell whether that is expected for noarch packages.

Checklist

• Build rule all-supported completed successfully (noarch build above completed)
• New installation of package completed successfully (Virtual DSM 7.2.2; the upstream package on DSM 7.4)
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Tested on a real DSM 7.4: the application (same code, as the upstream release package) runs on a real DiskStation with DSM 7.4, with an IONOS SSL certificate, 2-step verification enforced for all administrators and the DSM task; updates from earlier versions and renewals with installation into DSM were checked there.

The SynoCommunity build itself was tested on Virtual DSM 7.2.2: install, service as sc-advanced-acme, desktop window, Package Center texts, DSM notifications, CLI, stop/start, reinstall with data kept, uninstall with and without "delete data". The application is also covered by an end-to-end test (Pebble with EAB, mocks of the DSM Web API and the IONOS DNS API).

Type of change

• New Package

[github-actions]

Could you mark this pull request as a Draft while you iterate, and Ready for
review once CI is green? The button is under the title, or gh pr ready --undo.

Draft is what our CI keys on: while a PR is a draft a new push cancels the build
the previous push started, and a fork's duplicate push build is skipped. On a
non-draft PR nothing is cancelled and every push queues behind the last -- a full
matrix build costs hours of runner time, shared with everyone else waiting.

See Open It as a Draft.

[mreid-tt]

I've not read all the package description but how is this different from #7303? If there are genuine improvements over that project, did you consider contributing them to the upstream https://github.com/mritd/dnsacme/ rather than crafting a new one?

[SoulInfernoDE]

Thanks for looking! Short version: it covers cases dnsacme can't, and closing that gap would mean rewriting dnsacme rather than patching it.

Where they differ (checked against dnsacme's current code):

	dnsacme	Advanced ACME
DSM enforces 2-step verification for all admins	not supported: it signs in with a stored admin password, and its code notes that accounts needing an OTP are not supported	works: an optional root task installs certificates locally with synowebapi, no admin password stored
CAs in the DSM wizard	Let's Encrypt, ZeroSSL	also IONOS SSL and any ACME server with External Account Binding
DNS providers	11	200+ (all acme.sh plugins), incl. IONOS
Interface languages	English, Chinese	all 20 DSM languages

The starting point was a real setup: an IONOS SSL certificate (EAB, 180-day validity) on a DiskStation where 2FA is mandatory for every admin. With dnsacme, neither the CA, the DNS provider nor the DSM import work there.

Why not upstream: dnsacme is a single Go binary built on CertMagic; Advanced ACME is a DSM front end for acme.sh. Bringing the acme.sh DNS plugins, EAB CAs and the 2FA-safe install path into dnsacme would replace both its ACME engine and its DSM deployment, which is a different project rather than a contribution. The two can coexist: dnsacme stays the lean option for its providers, Advanced ACME covers IONOS, the long tail of DNS providers and NAS with enforced 2FA.