ACME Client "Invalid Domain" error in Version 25.7.7_4

Started by 300cpilot, December 22, 2025, 10:46:59 PM

Previous topic - Next topic
Just curious if this was fixed From Github bug "ACME client and dns_opnsense.sh broken - "Invalid domain" #4964"

I am running version:

OPNsense 25.7.7_4-amd64


Will update this evening, but am curious if Lets Encrypt made the changes called out in the bug report? Both the cron job and running a cert renew fail. I have created a new API with cloudflare as well. Many Thanks!

2025-12-23T04:23:23
acme.sh
[Tue Dec 23 04:23:23 +07 2025] Error adding TXT record to domain: _acme-challenge.DOMAIN
2025-12-23T04:23:23
acme.sh
[Tue Dec 23 04:23:23 +07 2025] invalid domain

January 04, 2026, 11:57:46 AM #1 Last Edit: January 04, 2026, 12:11:56 PM by torgeir Reason: Was not on the latest version.
I am also seeing this, with an untouched configuration that has previously been working.

> Currently running OPNsense 25.7.9_7 (amd64) at Sun Jan  4 11:54:40 CET 2026

Edit:
Noticed an update, so I updated. Still the same on
> Currently running OPNsense 25.7.10 (amd64) at Sun Jan  4 12:08:55 CET 2026

January 08, 2026, 09:32:28 PM #2 Last Edit: January 08, 2026, 09:35:51 PM by torgeir Reason: Forgot words
To me it seems that the regexp on line 209 of /usr/local/share/examples/acme.sh/dnsapi/dns_cf.sh does not match the returned content from cloudflare, causing the invalid domain error.

I changed line 209 from this

sed -n 209p /usr/local/share/examples/acme.sh/dnsapi/dns_cf.sh.20260108.bak
      _domain_id=$(echo "$response" | _egrep_o "\[.\"id\": *\"[^\"]*\"" | _head_n 1 | cut -d : -f 2 | tr -d \" | tr -d " ")


to this (its line 210 here as I added a comment above it, the bracket in _egrep_o regex is the only thing that changed)

> sed -n 210p /usr/local/share/examples/acme.sh/dnsapi/dns_cf.sh
      _domain_id=$(echo "$response" | _egrep_o "\"id\": *\"[^\"]*\"" | _head_n 1 | cut -d : -f 2 | tr -d \" | tr -d " ")


Which seems to fix this.

This gave me a new kind of error: A 403 "User account ID doesn't match account ID in authorization" and recreated my token with Zone Zone Edit and Zone DNS Read permissions. I removed "CF Account ID" from Services -> ACME Client -> Challenge Types, and now only use

- CF API Token
- CF Zone ID (Optional)

It works again.

I don't know what changed and I don't like the solution, as I'm not sure its an OK one in all scenarios.

Kinda baffled that the acme.sh master branch also has this.

The code is incredibly brittle. I'm surprised it works at all tbh.