Messages

I started this topic from a genuine interest in getting the whole certification chain "secure". Not a rigid requirement as I am in a happy place, I trust the network behind my OPNSense. Therefore I am happy to do end the "correct" certificate chain at the firewall and have self-signed stuff behind my reverse-proxy. this works fine and achieves the goal of having the SSL checks and balances on the internet correct (also in the browser), all the way to the backend services.

midclt, https://github.com/truenas/api_client, is required for using TrueNAS websocket API.
The script may work after installing it.

Also, midclt isn't what you linked on github. You linked to a script that calls `midclt` LOCALLY, which in turn is present by default on any TrueNAS install.

Now, this is incorrect. fragrance744 is correct. midctl is designed for remote use. midcli (t=i) (https://github.com/truenas/midcli) is local tool and in ALPHA state. Single letter difference, both on GitHub.

I'll ask again: why not use SSH with public key authentication to execute the midclt command on TrueNAS from OPNsense?

Personally, I am unable to get this working (maybe I can spin up my Claude AI... ;)). While midclt is installed by default on TrueNAS, it should be possible to also use the Websocket API from plugin code, right? This is imho the most elegant solution its per-design way of doing thing.

Bummer is that I am not a developer, am not sure if my aforementioned ideal solution is possible, but let's play nice to each other. I am very happy with the community to build the plugins with all the cool options that OPNSense is bringing to the table. I would contribute if able, and vibe-coding something without understanding its full working is something that creates shortcircuits in my head.

Bottom-line and summarizing there are five viable options:
1) Do not complete the cert chain all the way to the backend services, stop it at the reverse proxy and use selfsigned from there to the backend (my current solution, fine for my home network)
2) Use the SSH option that Patrick suggests and run midclt on the TrueNAS box locally. Basically this also uses the Websocket API, but only through the localhost. The API on TrueNAS apparently listens on localhost as well.
3) Use the ACME client automation with the older implementation. This works for TrueNAS 25.x.x and older.
4) Install the midclt on the OPNSense box. Hopefully this would make ACME client plugin automation (Websocket API) work again and use that. If not, this would require (shell) coding eveything on the OPNSense box. I would say "revert to 2)"
5) Update the ACME client plugin and code something that does not rely on midclt. Basically, remove the apparent bug from this piece of plugin.

The bigger change might actually be openssl 3.5.x in 26.7 for the packages

Arent't pf changes like VLAN on bridges a massive change as well? Can imagine that this would require a substantial change in the opnsense logic etc.

Shouldn't the automation "simply" use SSH to execute whatever is necessary on the TrueNAS system, including midclt?

I am not skilled enough to check what the acme client and plugin does on OPNSense (use local midctl OR remote calling through SSH or something else HTTP calls etc.). What I understand is that midctl is/was intended to make calling the TrueNAS API as easy as possible.

[Thu May 14 14:56:38 CEST 2026] Checking TrueNAS health...
/usr/local/sbin/acme.sh: midclt: not found

It seems to be a part of this:
https://github.com/truenas/api_client

Thanks for finding this apparently missing API client. I reproduced this missing midclt also from a shell. Not sure why it does not show up in the system logs though. ;-)

In either case it looks like it expects TrueNAS as OS, not OPNsense.

Cheers,
Franco

What's in a name... the TrueNAS client apparently called midcli and the one ceel references (https://github.com/truenas/api_client) is midclt. To make it more confusing both the clients seem to be preinstalled on a TrueNAS box according to the GitHub documentation.

Anyway,

• the midcli is the NAS cli interface —> that is preinstalled and can only be used (in my understanding) on the TrueNAS box.
• The midclt is not installed by default, at least not on my TrueNAS scale box (25.10.3.1). It is compatible with TrueNAS SCALE (Debian based) according to the docs both also to run from non-TrueNAS clients. "TrueNAS comes with this client preinstalled, but it is also possible to use the TrueNAS websocket client from a non-TrueNAS host."

Hence, imho the midclt could be used (assumption here, if the code works on FreeBSD...) to complete the deployment task.

If you want to dive even deeper: try to query the TrueNAS API endpoint "system.ready" using `curl` and your API key. The API documentation is available here:
https://www.truenas.com/docs/api/scale_websocket_api.html
It should make the root cause more obvious, but crafting the `curl` command might be a challenge.

I'll start by fiddling with cli on the TrueNAS box, the api client. See where I end up there

Hmmm... okay.. wasn't aware that TrueNAS API needed any configuration, but I'll dive into that one next. Thanks! I'll report back when I find something.

[Does this has something to do with setenv being done once (at the HTTPS scheme that worked) and that the system now has an API key but with older value..? I tested the old scheme first today to check my understanding before retrying the Websocket with new key. So, initialization thing?]

OK... So, I flicked open my iPad and tried again, as suggested.

Firstly I tested the deprecated API system. That worked as expected when filling in the values and with a new API-key. Used the HTTPS scheme and it exported the certificate as it should. No errors. Ohh, and leaving out the "X-" integer index does break the API and generated an API key error. Tested both, so answered my own question.

ACME log working:
2026-05-05T20:59:25acme.sh [Tue May 5 20:59:25 CEST 2026] Success
2026-05-05T20:59:25acme.sh [Tue May 5 20:59:25 CEST 2026] Reloading TrueNAS web UI
2026-05-05T20:59:25acme.sh [Tue May 5 20:59:25 CEST 2026] Deleting old certificate
2026-05-05T20:59:25acme.sh [Tue May 5 20:59:25 CEST 2026] FTP certificate is not configured or is not the same as TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] Checking if FTP certificate is the same as the TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] S3 certificate is not configured or is not the same as TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] Checking if S3 certificate is the same as the TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] WebDAV certificate is not configured or is not the same as TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] Checking if WebDAV certificate is the same as the TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] Current activate certificate ID: 5
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] Fetching list of installed certificates
2026-05-05T20:59:21acme.sh [Tue May 5 20:59:21 CEST 2026] Uploading new certificate to TrueNAS
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] Getting current active certificate from TrueNAS
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] Detected TrueNAS system version: unknown
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] Detected TrueNAS system os: unknown
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] Getting TrueNAS version
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] TrueNAS system state: "READY".
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] Testing Connection TrueNAS

Knowing that the deprecated API HTTPS scheme works gives confidence in the input fields. Using the same API key, but now with the websocket (ws, wss, none) results in a different error now. The environment variables seem OK, but it is 100% the same API key that works in HTTPS scheme. I cloned the working HTTPS one. And double checked.

The ACME log:
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Error encountered while deploying.
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Error deploying for domain: *.<REDACTED>.nl
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Verify API key.
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Please check environment variables DEPLOY_TRUENAS_APIKEY, DEPLOY_TRUENAS_HOSTNAME and DEPLOY_TRUENAS_PROTOCOL.
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] TrueNAS is not ready.
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Checking TrueNAS health...
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Environment variables: OK
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Checking environment variables...

System log in ACME client:
2026-05-05T21:12:22opnsense AcmeClient: running acme.sh deploy hook failed (acme_truenas_ws)
2026-05-05T21:12:22opnsense AcmeClient: AcmeClient: The shell command returned exit code '1': '/usr/local/sbin/acme.sh --deploy --syslog 6 --log-level 1 --server 'letsencrypt' --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/67e6acd371dce3.58753914' --certpath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/cert.pem' --keypath '/var/etc/acme-client/keys/67e6acd371dce3.58753914/private.key' --capath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/chain.pem' --fullchainpath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/fullchain.pem' --domain '*.<REDACTED>.nl' --ecc --deploy-hook truenas_ws --insecure'
2026-05-05T21:12:22opnsense AcmeClient: running automation (acme.sh): TrueNAS-export
2026-05-05T21:12:22opnsense AcmeClient: running automations for certificate: *.<REDACTED>.nl

Yesterday the ACME logs were different doing the same. Does this has something to do with setenv being done once (at the HTTPS scheme that worked) and that the system now has an API key but with older value..? I tested the old scheme first today to check my understanding before retrying the Websocket with new key. So, initialization thing?

AMCE logs yesterday:
2026-05-04T20:48:12acme.sh [Mon May 4 20:48:12 CEST 2026] Error encountered while deploying.
2026-05-04T20:48:12acme.sh [Mon May 4 20:48:12 CEST 2026] Error deploying for domain: *.<REDACTED>.nl
2026-05-04T20:48:12acme.sh [Mon May 4 20:48:12 CEST 2026] TrueNAS API key not found, please set the DEPLOY_TRUENAS_APIKEY environment variable.
2026-05-04T20:48:12acme.sh [Mon May 4 20:48:12 CEST 2026] Checking environment variables...

System logs yesterday:
2026-05-04T20:48:12opnsense AcmeClient: running acme.sh deploy hook failed (acme_truenas_ws)
2026-05-04T20:48:12opnsense AcmeClient: AcmeClient: The shell command returned exit code '1': '/usr/local/sbin/acme.sh --deploy --syslog 6 --log-level 1 --server 'letsencrypt' --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/67e6acd371dce3.58753914' --certpath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/cert.pem' --keypath '/var/etc/acme-client/keys/67e6acd371dce3.58753914/private.key' --capath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/chain.pem' --fullchainpath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/fullchain.pem' --domain '*.<REDACTED>.nl' --ecc --deploy-hook truenas_ws --insecure'
2026-05-04T20:48:12opnsense AcmeClient: running automation (acme.sh): TrueNAS_cert
2026-05-04T20:48:12opnsense AcmeClient: running automations for certificate: *.<REDACTED>.nl

But if Frankie says it's not that, he is correct.

Copy all. I'll try and get all the logs on the forum asap.

I have tested this and was unable to reproduce this issue.
Please try again and provide the full ACME Log and all "AcmeClient" entries from the System Log.

I can do this when I have computer access again in a few days.

However, sopex mentions it will be fixed in the next version.... This indicates bug...

Maybe the setenv variable had been set in your case earlier and therefore it works? Is that possible?

Regardless, i'll dig into it in a few days time and help out isolating any issue. Thanks

Hi,

I have a working ACME client setup with a wildcard Let's Encrypt certificate for my domain. Also have a working nginx based reverse proxy to three services. Those services are running on a TrueNAS SCALE 25.10.3 (latest patch) system.

While all https access to the services is working fine through nginx with A+ trusted HTTPS (reverse proxy handles upstream stuff on the LAN to TrueNAS) the services on the TrueNAS system still use selfsigned certs from the TrueNAS box.

Now, while not essential (I trust my home lan ;-)) I am trying to get the whole certificate chain proper. Just a hobby thing.

Therefore I made an API key (root) on my TrueNAS and created the automation in the ACME client. Used the websocket (not deprecated one). Filled in all the fields, which are self explanatory. Reran the automations from the commands in OPNsense but the upload errors out.

[Mon May 4 18:02:46 CEST 2026] TrueNAS API key not found, please set the DEPLOY_TRUENAS_APIKEY environment variable.

I tried all automation modes (none, ws and wss) but error remains. The API key is really in the appropriate field. The plugin however does not seem to set the value from the field in the environment variable.

I am a little at hand (no ssh) from my phone currently so no CLI attempt possible.

Anybody recognize this? Seems a bug...

Hi,

Just did a post-upgrade security audit on the packages. Noticed that curl 8.17 is vulnerable with multiple CVEs. I am not knowledgeable enough to check if these CVEs can be an issue for curl use in OPNsense, but just to flag this one as curl is widely used.

Is it planned to be upgraded in the next release?   

***GOT REQUEST TO AUDIT SECURITY***
Currently running OPNsense 26.1.5 (amd64) at Thu Mar 26 21:53:45 CET 2026
vulnxml file up-to-date
curl-8.17.0 is vulnerable:
  curl -- Multiple vulnerabilties
  CVE: CVE-2026-1965
  CVE: CVE-2026-3783
  CVE: CVE-2026-3784
  CVE: CVE-2026-3805
  WWW: https://vuxml.freebsd.org/freebsd/1933737d-1d46-11f1-81da-8447094a420f.html

  curl -- Multiple vulnerabilities
  CVE: CVE-2025-13034
  CVE: CVE-2025-14017
  CVE: CVE-2025-14524
  CVE: CVE-2025-14819
  CVE: CVE-2025-15079
  CVE: CVE-2025-15224
  WWW: https://vuxml.freebsd.org/freebsd/086d53fa-1d47-11f1-81da-8447094a420f.html

2 problem(s) in 1 package(s) found.
***DONE***

Hi all,

Just upgraded to 25.7.11_1 from 25.7.10. Everything works as normal. Fiddling around with the new feature Interfaces: Neighbors: Automatic Discovery. Noticed that it works, but only with All interfaces selected. Any other subselection of interfaces, including Select All, prevents the service from starting.

See below for examples. When looking at the log (when using All) shows that the adds capture for the various interface devices. I have bridges configured (multiple eth-devices into different LANs (IOT and NET for example) and have pppoe0 as WAN (VLAN6 on physical interface - KPN FttH).

One error always shows up, and does not seem related. Is there when it works, and when the service does not start. No other logs are available in the GUI that show the reason for the service failing. Using promiscuous mode does not make a difference, nor does verbose logging for figuring out what is going wrong. All my interface types can be captured apparently...   

Successful when All:
2026-01-17T13:10:02.890816Z INFO hostwatch: Added capture for device: pppoe0 (WAN_INET (wan))
2026-01-17T14:10:02Noticehostwatch 2026-01-17T13:10:02.890344Z INFO hostwatch: Added capture for device: bridge1 (LAN_IOT (opt12))
2026-01-17T14:10:02Noticehostwatch 2026-01-17T13:10:02.889866Z INFO hostwatch: Added capture for device: bridge0 (LAN_INET (lan))
2026-01-17T14:10:02Noticehostwatch 2026-01-17T13:10:02.889356Z INFO hostwatch: Added capture for device: wg0 (ViperWG (opt13))
2026-01-17T14:10:02Noticehostwatch 2026-01-17T13:10:02.888815Z INFO hostwatch: Added capture for device: vlan03 (LAN_IPTV (opt10))
2026-01-17T14:10:02Noticehostwatch 2026-01-17T13:10:02.888242Z INFO hostwatch: Added capture for device: vlan02 (WAN_IPTV (opt8))
2026-01-17T14:10:02Noticehostwatch 2026-01-17T13:10:02.887692Z INFO hostwatch: Added capture for device: vlan01 (No description)
2026-01-17T14:10:02Noticehostwatch 2026-01-17T13:10:02.887166Z INFO hostwatch: Added capture for device: igb7 (ETH8 (opt9))
2026-01-17T14:10:02Noticehostwatch 2026-01-17T13:10:02.886684Z INFO hostwatch: Added capture for device: igb6 (ETH7 (opt11))
2026-01-17T14:10:02Noticehostwatch 2026-01-17T13:10:02.886156Z INFO hostwatch: Added capture for device: igb5 (ETH6 (opt6))

Error always visible (regardless if the service does or does not start):
2026-01-17T13:10:02.914762Z WARN hostwatch: Failed to initialize capture for device: pfsync0

Edit: Found some logs in the general log in settings.

At failure to start:
2026-01-17T14:15:15Noticekernel <6>[1488] pid 81926 (hostwatch), jid 0, uid 0: exited on signal 6 (no core dump - bad address)
2026-01-17T14:15:15Noticeroot /usr/local/etc/rc.d/hostwatch: WARNING: failed to start hostwatch
2026-01-17T14:14:54Noticekernel <6>[1467] pid 29596 (hostwatch), jid 0, uid 0: exited on signal 6 (no core dump - bad address)
2026-01-17T14:14:54Noticeroot /usr/local/etc/rc.d/hostwatch: WARNING: failed to start hostwatch

At successful start: no logs related to the service in General. Only the change in config XML file (enabled check).

Currently you can bridge VLAN interfaces but not the other way round.

E.g. with FreeBSD 14:

igc0.1 - VLAN 1 on igc0
igc0.2 - VLAN 2 on igc0
igc1.1 - VLAN 1 on igc1
igc1.2 - VLAN 2 on igc1

bridge1 - members igc0.1, igc1.1
bridge2 - members igc0.2, igc2.2

This works well but is complicated and error prone to set up.

With FreeBSD 15:

bridge0 - members igc0, igc1

bridge0.1 - VLAN 1 on all bridge ports
bridge0.2 - VLAN 2 on all bridge ports


HTH,
Patrick

Will this also be implemented in OPNsense? Not sure if all FreeBSD options are also implemented in OPNsense

Happy New Year!

Searching the forum for VLANs on bridges results in a lot of information and configurations (e.g. link, link, link) where the bottomline seems to be "bridge over VLANs" and not use (not possible in OPNsense config) VLANs on bridges.

Now I have been reading up on the matter and see that"

• in FreeBSD 14.x man for IF_BRIDGE(4) there is no VLAN support (link)
• in FreeBSD 15.x man for IF_BRIDGE(4) there is VLAN support (see quote below, link)

Where I am aware that OPNsense is currently based on FreeBSD 14.3 I assume that OPNsense will move to 15.x at some point. this will offer VLAN support on bridges judging by the FreeBSD documentation.

Is this VLAN support on bridges also moving into OPNsense? Couldn't find it on the forum, but when is OPNsense moving to FreeBSD 15.x/16.x?
Arguably, having VLAN support on bridges could make multi-NIC box configurations (such as my trusty Qotom) a little easier with IPTV VLANs, WLAN VLANs, IOT VLANs etc. on top of a multi-NIC LAN_bridge with a single WAN interface. ;-) 

From the FreeBSD 15.x man IF_BRIDGE(4)

VLAN SUPPORT
       The if_bridge driver has   full support for virtual  LANs   (VLANs).   The
       bridge  implements  independent   VLAN  learning,   i.e. MAC addresses are
       learned on a per-VLAN basis, and   the same MAC address may be learned on
       multiple   interfaces on different   VLANs.   Incoming frames   with an   802.1Q
       tag will   be assigned to the appropriate VLAN.

       Traffic sent to or from the host   is not assigned   to a VLAN by  default.
       To  allow the host to communicate on a VLAN, configure a   vlan(4)   inter-
       face on the bridge and (if necessary) assign IP addresses there.

       By default no access control is enabled,   so any interface may  partici-
       pate in any VLAN.

       VLAN  filtering   may  be    enabled  on  a    bridge    using the ifconfig(8)
       vlanfilter option.  When   VLAN filtering is enabled,  an   interface  may
       only send and receive frames based on its configured VLAN access   list.

       The   interface's   untagged  VLAN  ID  may  be   configured  using  the
       ifconfig(8) untagged option.  If   an untagged VLAN ID is configured, in-
       coming frames will be assigned to that VLAN, and   the interface may  re-
       ceive outgoing untagged frames in that VLAN.

       The tagged VLAN access list may be configured using the tagged, +tagged
       and  -tagged options to ifconfig(8).  An   interface may send and receive
       tagged frames for any VLAN in its access   list.

       The bridge will automatically insert or remove 802.1q tags  as  needed,
       based  on  the  interface configuration,   when forwarding   frames between
       interfaces.  This tag processing   is only   done for interfaces with  VLAN
       filtering enabled.

My IGMP Proxy is definitely throwing errors and the behaviour of my network is entirely in keeping with what you would expect from IGMP failure.
I wonder if the error i saw when performing the upgrade is the cause.
Is it possible to rerun the upgrade over the top of the existing upgrade (ie 25.10.7 over 25.10.7) to eliminate this as the possible root cause.

Maybe it is a better idea to uninstall the IGMP Proxy plugin first, reboot the system, reinstall the IGMP Proxy plugin and configure it from scratch. Reinstalling the plugin will trigger the system to register everything (whatever it requires) again from scratch. Maybe there is a corrupt file or something. If that doesn't do the trick, you may need a reinstall. Dunno if you can reinstall the upgrade the way you describe.