uacme: use acme-common and make it able to use acme.sh dns apis

[orangepizza]

📦 Package Details

Maintainer: @lucize

Description:

• remake uacme hook based on acme-common's call structure, and allow acme virtual package can satisfied by uacme so it can be used with luci-app-acme. and I scrapped functions that used by acme.sh dnsapis and striped it's implementations into separate shell script, dnsapihelper.shand linked into dns challenge hook, so uacme can use dns api from acme.sh without any modification from api side: they want curl or wget, and as uacme already depends on libcurl so I set curl as dependency so I changed dependency to acme-common +acme-acmesh-dnsapi if uacme is selected. while I copied most of acme.sh functions relevant form acme.sh, some if it's function is depend on OpenSSL. while re implemented some in ucode, some crypto functions like sign() and isecc etc will only work when you have OpenSSL, but as only about 10% of 304 scripts calls that I hope one can user themselves can install openssl if needed by their API.
• while this does call ualpn server if config file is set to, it's user's duty to set ualpn server as needed as same as old version does. Not sure if it's safe to do this automatically because it'd need shutdown uhttpd to allow ualpn to listen port 443. original, same reason it doesn't support standalone validation, because uacme doesn't come with to do that.

---

🧪 Run Testing Details

• OpenWrt Version: snapshot
• OpenWrt Target/Subtarget: x86_64, but only things it touched is shell scripts so shouldn't matter
• OpenWrt Device: a kvm virtual machine

tested it can issue and renew certificate with uacme as backed, with config set from uacme without Openssl installed with duckdns /cloudflare/ webroot. (acme-common handles opening port when needed if I read code currectly)

due to upstream bug in uacme, this well log a line of error in for not parsing ari info, but it's already fixed in their master branch and just waiting a new release for them.
and uacme never rotate key by itself, until not-released yet version in master branch.

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

[mundschenk-at]

It looks like this reworking of the scripts drops both the support for custom CA URLs and the TLS-ALPN-01 challenge. I assume this is not intentional?

[orangepizza]

It does keep custom ca url (I tested on pebble entire time. See line 45 onword from hook.sh

Tls-alpn-01 was never fully done (ulpn.sh was called bit never prepared to run its deamon)

[mundschenk-at]

It does keep custom ca url (I tested on pebble entire time. See line 45 onword from hook.sh

So what's the config key for that, acme_server (I've got no knowledge of acme-acmesh and the wiki at was silent on that at least in early 2024)? uacme uses acme_url (and acme_url_staging) since #23097. I'm not opposed to unifying that, but it needs documentation and/or a migration script.

Tls-alpn-01 was never fully done (ulpn.sh was called bit never prepared to run its deamon)

It was implemented for uacme in #23097 (with manual ualpn setup as described in the PR).

[orangepizza]

I assumed acmesh and uacme hook wouldn't diverged so just took scripts for acme-common from acme-acmesh and fit uacme command line options as that was what need for luci app acme

[mundschenk-at]

Yeah, that's why I'm speaking up (it was a happy accident that I saw your PR, as this was my first and so far only code contribution to a package and I don't often visit this repo). Let's see how @lucize wants to resolve the URL issue.

[orangepizza]

made a migration script, I migrated acme_uri to acme server but removed acme_uri_staging because there's no ui way to see that, and acme.sh hook sets to acme_server even if --staging is set. and I noticed bug in my hook about renewal in process (acme.sh marks staging cert as but we can't set custom server and staging at same time) so fixed it to

[lucize]

I gave up with using the common package because at that time uacme didn't support all ssl packages that acme supported without adding additional ssl library and all was about smaller packages, you have to bear in mind that, by default both acme and uacme will be built by buildbot

[orangepizza]

as openwrt now moved back to mbedtls by default and it's supported by uacme (and openssl too) I think it can surely save space in most configuration, so I think it worth the effect. (does anything use wolfssl in openwrt context?)
some api like oracle, yandex, TransIP.nl (just those 4 out of 300ish apis) still need openssl for _sign function
but did most other functions in shell script or ucode

[orangepizza]

uacme upstream updated 1.8.0 with bugfix about musl (which openwrt uses)

[lucize]

thanks
can't test the dns api, otherwise LGTM

[orangepizza]

@lucize if you don't mind I want to add support for dns-perssis-01 challenge: as it most likely solve need of open port 80/443 or give full dns api key on router to run certificate renewal
https://letsencrypt.org/2026/02/18/dns-persist-01

[hnyman]

cc @tohojo who is the maintainer of some of the affected packages according to the Makefile(s).

[tohojo]

I have only looked at the shared bits, not the uacme changes themselves. These shared bits LGTM :)

[mundschenk-at]

@orangepizza Can you test whether ualpn actually works with mbedtls? The current standard binaries seem to run, but don't actually proxy correctly. Custom builds with openssl work fine. If this is not easily fixable, I think compilation with mbedtls should be disabled.

[orangepizza]

@orangepizza Can you test whether ualpn actually works with mbedtls? The current standard binaries seem to run, but don't actually proxy correctly. Custom builds with openssl work fine. If this is not easily fixable, I think compilation with mbedtls should be disabled.

--dig upstream and it looks like it had bug on mbedls version a bug that - in token got deleted before encoded to binary in alpn challenge certificate.--
edit: it was my keyboard being flakey, sorry:

it work as challenge solver, so If one wanted it you can move luci permanently out of port 443 and still work (we don't start ualpn as start daemon anyway.) do I don't think it worth delectation.

[ndilieto]

@orangepizza Can you test whether ualpn actually works with mbedtls? The current standard binaries seem to run, but don't actually proxy correctly. Custom builds with openssl work fine. If this is not easily fixable, I think compilation with mbedtls should be disabled.

Fixed upstream in version 1.8.1

[orangepizza]

rebased for update for 1.8.1 instead of 1.8.0. fixing issue/29003 while doing that squashed fixup commits from reviews