Hi,
the release cadence of acme.sh can be slow with gaps of up to a year. If I understand the readme correctly, one should use the latest code instead of waiting for new tags anyway:
Quoteacme.sh is in constant development, so it's strongly recommended to use the latest code.
Since the last release from April, useful new features such as the DNS API of Hurricane Electric have been added. Would it be possible to update OPNsense with the latest code from github? Thanks!
Acme.sh repository tags a release
FreeBSD ports picks it up and bumps packet version
Opnsense ports synchronize that
New package gets built and released
Its that flow of events that must usually happen.
Using latest for new things is useful, using it for existing things is risky.
Getting fixes into FreeBSD ports is also not really an option as FreeBSD doesn't really consider downstream an important factor.
Case in point https://github.com/opnsense/ports/commit/95f5a824aa
Cheers,
Franco
Thank you both for the insights! So it's either back to waiting for a new release tag or building from git myself.
As shown we can do small backports into our ports tree if they serve a purpose. Pulling in everything is not a good idea.
Cheers,
Franco
PS: Long time no see, hope you are doing good :)
You're absolutely correct, pulling in everything is probably just asking for trouble. Yet, doing individual pulls for non-critical issues creates too much work for projects as big as OPNsense.
I felt somewhat naked without having 2FA activated on my Hurricane Electric account. However, as HE apparently doesn't support global access tokens, that requires ACME.sh to support record-specific API keys - which is safer anyways: https://github.com/acmesh-official/acme.sh/pull/5237 (https://github.com/acmesh-official/acme.sh/pull/5237)
Cheers,
Fabian
PS: Thank you, I'm doing great and hope you are as well! :-)
You're looking for https://github.com/acmesh-official/acme.sh/commit/0ae80272f specifically?
It probably also needs an addition to os-acme-client plugin?
Yes, doing great all things considered. :)
Cheers,
Franco
Glad to hear it! :-)
Yes, that's the commit.
I assumed it to be integrated in a way that simply takes the user/password input in ACME's challenge types. But that was overly optimistic to naive. Guess I should finally RTFM the plugin documentation^^
I tried to add the upstream commit but it's already in 3.1.1?
Cheers,
Franco
Layer 8 strikes again (๑﹏๑//) Sorry for sending you on a wild goose chase! It's indeed already in 3.1.1, this is simply a case of GUI integration.
As a test I added HE_DDNS_KEY="the_generated_key" in /var/etc/acme-client/accounts/[...]/account.conf, called acme.sh with --dns 'dns_he_ddns' instead of --dns 'dns_he' and the certificate is created.
Currently, in the GUI username/password are supplied for all domains under "Challenge Type". As this new feature is per-domain, it's probably reasonable to add a checkbox which enables per-domain tokens to be supplied in each certificates' dialogue?
Best to raise a plugin ticket on GitHub. Frank doesn't have a lot of time at the moment it seems, but maybe he sees your question and can respond.
Cheers,
Franco