pfSense » pfSense Packages

So I updated a CA that was about to expire a month and a half ago (September 2024) on a pfsense host.

When a CA certificate is renewed in pfSense, the change is not propagated to the actual configuration files where this CA is selected for the zabbix package.
While the web interface indicates all Certs are up to date, they silently expire and zabbix suddenly ceases to work.

Inspecting the files on the file system reveals:

openssl x509 -in /usr/local/etc/zabbix6/zabbix_proxy.ca -noout -text | grep "Not After" 
            Not After : Nov 10 13:47:31 2024 GMT

Inspecting the runnign processes also reveals:

ps aux | grep zabbix_proxy | head -n 1
    zabbix   3473   0.3  1.2  85928 44068  -  S    19Jun24     275:45.97 zabbix_proxy: poller #3 [got 2 values in 0.048969 sec, getting values] (zabbix_proxy)
   (...)

Note that this proxy has been restarted last in June. This means that even though its CA was changed, it's still running with the old CA in memory. This is difficult to tell from the webGUI and can lead to unexpected 'SSL CERTIFICATE EXPIRED' errors biting the user months after they thought they properly renewed their CA file. While I laud pfSense for not entirely rebooting with every small change like commercial routers do, this does mean having to properly do related tasks like restarting affected programs or services when config data they depend on changes or you get this incongruent behaviour.

Re-starting the proxy in the GUI is insufficient to update the configuration either; there is no check whether the ca/cert in the config dir matches the one in config.xml on (re)starting a service.
Manually updating the file via ftp over ssh does the trick, as does the following quirk:
If the CA is set to 'None' and then restored to the previous value, the proxy will also restore functionality without going into the command line, by changing the conf file and deleting the ca file, restarting the proxy, then changing the conf file back to what it was and copying the ca file from config.xml again and restarting a second time. Inefficient and hacky but easier for the user than using terminals.

It shouldn't be expected for users to SSH in to fix config files in undocumented places when a certificate or CA is changed in the webGUI that all packages (VPNs, zabbix. etc.) that use that certificate or CA will have their configurations updated to the new version.

In fact, ideally, packages that depend on a CA or Cert should be restarted when that CA or Cert is changed. The information is present in the UI after all.