uacme: adapted run.sh script to get it working with step CA

[oldboys92]

Maintainer: @lucize
Compile tested: OpenWrt 23.05.03
Run tested: OpenWrt 23.05.03

Description:

Current uacme package has no support for using private CA (like step CA). The tool supports that, but the wrapper script responsible for handling the ACME challenge is missing additional settings required for that (see this thread).

On top of that, the wrapper script was initially forked from acme.sh package and contains code snippets which suggest wrapper is same when uacme and acme.sh are installed. This makes no sense, so I've decided to fix the wrapper script (run.sh) to support only uacme package.

Added support for tls-alpn-01 and tested http-01 and tls-alpn-01 ACME challenge types using step CA as ACME service. Also fixed and improved the pre_check() and post_check() functions of the wrapper. Added also option for setting which interface should listen on the ACME challenge.

[github-actions]

OpenWrt will change to the APK package manager which requires
deterministic verisons. Please make sure that PKG_VERSION
follows Semantic Versioning or more specifically,
the APK version scheme.
If the version is based on a date, please use dots instead of dashes, i.e. 24.01.01.

The PKG_RELEASE should be an integer and not contain any letters or special characters.

• net/uacme/net/uacme/Makefile

[oldboys92]

@lucize I prepared everything once again, kindly asking for your review.

[oldboys92]

@lucize friendly reminder for reviewing this PR

[lucize]

LGTM

[oldboys92]

@lucize github pr workflow requires your approval, would you be so kind?

[lucize]

Sorry but I don't have the rights to do it, seems it needs to be approved by a maintainer with write access

[Neustradamus]

@systemcrash: What do you think?

[systemcrash]

I don't use this stuff on my box. But this is difficult to review: there are stylistic fixes together with code changes. Does this come at the expense of no more compat with standard ACME endpoints?

[oldboys92]

@systemcrash I don't think a standard ACME server implementation will break, since the STEP CA ACME used for testing this was also tested by Let's Encrypt service.

Nevertheless I tested this only with an internal network hosted STEP CA ACME service, since my OpenWRT instance, where I need this, is not exposed to internet and can't use Let's Encrpyt standard ACME service.

[oldboys92]

@systemcrash

I don't use this stuff on my box. But this is difficult to review: there are stylistic fixes together with code changes. Does this come at the expense of no more compat with standard ACME endpoints?

please do enable hide whitespaces diff option, since there were quite mixed tabs and spaces indentations and this PR fixes these too. after hiding whitespace in the diff, the amount of changed code looks smaller and it should be clearer to read.

[stokito]

@oldboys92 maybe you can also check the unfinished #10792

[oldboys92]

@stokito you mean merging my changes for the run.sh into acme-common package, right?

I strongly believe we should not do this. Further more having acme-common supporting 2 acme packages (acme and uacme) will increase the effort to maintain a common code base. Maybe this is possible, but I don't have the time and the resources to do this at the moment not in the near future.

I like the KISS principle, so I think the package maintainers should give up and remove acme-common and let each package bring his wrapper and config files. Nobody should have both packages installed at the same time.

2. acme / acme.sh is a shell based ACME client and this was too big and with too many dependencies for my router with only 1 MB storage left for additional packages. so I looked for something more smaller.

3. uacme is really a very thin ACME client with a minimal footprint. perfect for my use case. then I've realized the wrapper run.sh script was forked from one supporting acme or uacme. Since I did not had place nor the hardware to test acme / acme.sh package, I remove that from the wrapper code.

I hope this makes sense to you. I would love to hear some feedback also from package maintainers as well.