TrueNAS SCALE, Let's Encrypt, NameCheap / Custom DNS, and freenas-deploy-py

My current setup is a TrueNAS system, formerly running CORE, with a VM running Virtualmin as a Web / Proxy / DNS server. Under this setup, the VM would pull a wildcard cert for my domain as needed, and I had a CRON job running on the VM that ran deploy-freenas from @dan . Everything worked smoothly.

After this, I migrated my TrueNAS from CORE to SCALE. After the migration, it seems that deploy-freenas works, as I see the cert being deployed to TrueNAS SCALE in the UI. However, the UI is not picking up on the new Cert, and is still using the older / current one, which is not how it acted in the past - previously, the old cert would be replaced by the new one.

I’m looking to re-automate things again so that my certs will automatically renew, and be deployed to the UI and (hopefully) any Apps that are using them as well.

My domains are currently at Namecheap, with the DNS hosted locally on the VM on my TrueNAS. Searching on this, it looks like Namecheap is not directly supported in the TrueNAS SCALE UI.

What are my options, to automate the renewal and deployment of the cert?

Thank you!

That also isn’t how it’s behaving for me under SCALE 24.04, so it’d be interesting to find out where it’s failing for you–the output of running deploy-freenas.py would be helpful in determining that.

What the script is supposed to do is:

  • Upload the new cert with a name (by default) of letsencrypt-yyyy-mm-dd-hhmmss
  • Set the UI to use that cert
  • Set services, optionally, to use that cert
  • Set apps, again optionally, to use that cert
  • Remove any certs whose names match letsencrypt- followed by the date stamp, that aren’t the one that was just uploaded
  • Restart the web interface, so it picks up the new cert

So other than the output of running the script, it’d be useful to look in the GUI to see how far it got. Is the new cert there (under Credentials → Certificates)? Are there any other certs there (other than the default)? Is the GUI set to use the correct cert (in System Settings → General)?

Hm. I went into Virtualmin, and ran the script manually from the command line, to see what it said. Here’s the output:

root@www:~/scripts/deploy-freenas# ./deploy_freenas.py
Certificate import successful
Certificate list successful
Error setting active certificate!
{
 "general_settings_update.ui_address": [
  {
   "message": "10.0.0.253 ipv4 address is not associated with this machine",
   "errno": 22
  }
 ]
}
root@www:~/scripts/deploy-freenas# 

I’m guessing this may be because I have a Bridge set up, for my VMs / Apps?

EDIT: So the certs are showing up in the UI. But it’s not setting them for the UI, or the Apps, despite being configured for this in deploy_config.

The Default Cert is still there. The UI is using one of the older certs, from Oct 27th - I am guessing that was shortly before I created the Bridge for my VM / Apps, I can verify that if needed. Current version of TrueNAS is 24.10.2

I wouldn’t think that’s the case; I likewise have a bridge set up on my NAS. What’s weird is that it’s reporting an error in general_settings_update.ui_address, and my script doesn’t call that function. Here’s the relevant code:

if UI_CERTIFICATE_ENABLED:
  # Set our cert as active
  r = session.put(
    BASE_URL + '/api/v2.0/system/general/',
    verify=VERIFY,
    data=json.dumps({
      "ui_certificate": cert_id,
    })
  )

  if r.status_code == 200:
    print ("Setting active certificate successful")
  else:
    print ("Error setting active certificate!")
    print (r.text)
    sys.exit(1)

Dan, I think I was editing while you were posting, just in case I added anything relevant.

Photos of my UI, below:

On second thought, I had the VM running before Oct. 27th. (You helped me set the bridge up on Sept. 2nd, I just went back and found the post.)

I wonder if this is an EE issue? I think this is around the time EE came out.

OK, I think I figured it out. When I looked in System => General Settings => GUI, the ipv4 address was not set, at all. Setting it to 0.0.0.0 seems to have solved this.

Thank you for the guidance!