ACME client and dns_opnsense.sh broken - "Invalid domain"

[micah-quinn]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [X ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [ X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

The ACME client in version 25.7.4 has a broken dns_opnsense.sh API hook. This breaks certificate renewal because the domain parser is incorrect and returns "invalid domain" for all valid domains. This was almost a very big deal for our organization because our customer facing certificates are 4 days away from expiring.

To Reproduce

Steps to reproduce the behavior:

1. Go to 'Services' -> 'ACME Client' -> 'Certificates'
2. Click on Issue or renew certificate'

Expected behavior

Certificate should renew, but instead "Last ACME Status" says "validation failed"

Describe alternatives you considered

I checked to make sure it wasn't my API token/key and that it wasn't specific to any one certificate. They are all failing.

Relevant log files

The ACME log file shows this as an example:

[Wed Oct  1 12:18:28 CDT 2025] h='cust.xyz.net'
[Wed Oct  1 12:18:28 CDT 2025] h='xyz.net'
[Wed Oct  1 12:18:28 CDT 2025] h='net'
[Wed Oct  1 12:18:28 CDT 2025] invalid domain
[Wed Oct  1 12:18:28 CDT 2025] Error adding TXT record to domain: _acme-challenge.cust.xyz.net
[Wed Oct  1 12:18:28 CDT 2025] _on_issue_err
[Wed Oct  1 12:18:28 CDT 2025] Please add '--debug' or '--log' to see more information.
[Wed Oct  1 12:18:28 CDT 2025] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh

Additional context

A fix is already noted on the ACME github: acmesh-official/acme.sh#6529

I've confirmed that in my case, replacing the dns_opnsense.sh in "/usr/local/share/examples/acme.sh/dnsapi/" fixes the issue. (BTW, is there any reason OPNsense's ACME client is using the "examples" directory instead of the "/usr/local/share/acme.sh/dnsapi" directory? This caused a lot of confusion for me as I was troubleshooting/debugging)

Environment

OPNsense 25.7.4 (amd64).

[benyamin-codez]

The PR with the fix is acmesh-official/acme.sh#6503.
The dev tree was merged into master by acmesh-official/acme.sh#6540 four days ago.
This affects the acme.sh package, not the plugin.

[benyamin-codez]

Also: https://forum.opnsense.org/index.php?topic=49115.0

[fichtner]

Yes, I missed the fact this was about acme.sh itself, because the question in the OPNsense scope this doesn’t play a relevant role.

Acme.sh needs to release its code in a new version, which needs to be picked up in FreeBSD ports which then lands in our ports tree which then lands in a release.

Reading JSON from the shell with grep is less robust than using something like jq. This will likely break again in the future when the API will be enhanced, but doesn’t actually “breaks again” in a future release. That conclusion is a bit too simplistic.

[micah-quinn]

@fichtner Sorry that I did not make that more clear, earlier. Although this is an issue with acme.sh itself, I thought it important to raise the alarm here because unrenewed certificates make for really bad Mondays. I don't know if the OPNsense team does hotfixes for things like this. If yes, perhaps this is a candidate for such a fix.

[Monviech]

@micah-quinn Please read again what @fichtner wrote.

• 1. Acme.sh needs to release its code in a new version
• 2. which needs to be picked up in FreeBSD ports
• 3. which then lands in our ports tree
• 4. which then lands in a release

It needs to be at least in our ports tree to be released. Which is synced from upstream.

https://github.com/opnsense/ports/tree/master/security/acme.sh

[fichtner]

With coordination we can speed up the process, but here we seem to have started with the wrong question of why it’s not there instead of how can we get it there.

I wouldn’t call this hotfix material though. This is a third party integration for a community plugin. But we can make sure it hits 25.7.5.

Cheers,
Franco

[benyamin-codez]

Acme.sh needs to release its code in a new version, which needs to be picked up in FreeBSD ports which then lands in our ports tree which then lands in a release.

@fichtner

Thanks Franco.

wrt acme.sh we are still relying on the April 24 v3.1.1 tag, with the last release being November 23 last year (v3.1.0).

The port is on v3.1.1_1 as released with v25.7.4. I had missed this. It looks like I had clicked through on a 2023Q2 branch search result and only saw v3.0.6.

I could reach out to the maintainer (Dan Langille) but we don't know each other. Otherwise, I can raise a FreeBSD bug if you think that might be helpful. We might be able to work towards a v3.1.1_2 port. Alternatively, perhaps @fraenki could work with @Neilpang in considering a new tag or release for acme.sh...

Reading JSON from the shell with grep is less robust than using something like jq. This will likely break again in the future when the API will be enhanced, but doesn’t actually “breaks again” in a future release. That conclusion is a bit too simplistic.

We could consider a roadmap to provide abstraction for dns_opnsense.sh BIND API calls via the os-acme-client plugin. We could then manage any schema changes within the OPNsense project.

Let me know how I might be able to help with any of the above.

Best regards,
Ben

[fichtner]

I don’t see that FreeBSD has ample interest in supporting downstream issues, at least it seems to be seen as a burden rather than useful collaboration from my experience.

We can fix this in our ports tree on Monday in time for 25.7.5. It’s also relatively easy to fix this manually for all the people currently affected (replace the script file).

As far as rearranging the workflow goes i think the script is entirely upstream design (acme.sh) and implementation doesn’t fit into our project and would likely break as well if they make an update to acme.sh that requires changes on our end, but these are hard to catch and test.

Either way you need someone to be proactive about maintaining that script wherever it is anchored, which is the only reason we see this reported already months after releasing 25.7 initially.

Cheers,
Franco