security/acme-client: deploy certificates with SFTP + DEPLOY_SSH_REMOTE_CMD

[fergbrain]

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

[✔️] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md

[✔️] I have searched the existing issues and I'm convinced that mine is new.

[✔️] When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
The os-acme-client plugin does not support DEPLOY_SSH_REMOTE_CMD.

In my particular situation, OPNsense procures LE certificates and transfer them via SFTP them to my various VM. However, the remote server (e.g. nginx) needs to be reloaded/restarted in order for the new certificate to take effect. DEPLOY_SSH_REMOTE_CMD is the mechanism that Acme.sh uses for this purpose (and gives examples to that effect at https://github.com/acmesh-official/acme.sh/wiki/deployhooks#examples-using-ssh-deploy)

Describe the solution you'd like
I would like an input field added to the existing "Upload certificate via SFTP" automation in the advanced options section to allow for a remote command to pasted (e.g. sudo /etc/init.d/nginx reload) and provided to the acme.sh script.

Additional context
This issue is related to related to #2627 (since closed). In that issue, the specific problem was around deploying to a Unifi controller, however there was a proposal to add DEPLOY_SSH_REMOTE_CMD (#2627 (comment)) was offered (though rejected), and a dedicated "Unifi (local)" option was added instead.

[kquinsland]

I just got hit by this as well.

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

I am trying to transition away from pfSense where I have a very simple shell script that transforms the certificate material into java format before copying it over and then installing it and restarting the web app. This is possible because of two things:

• It is trivial to tell the acme.sh client to call the shell script after successful cert issue.
• The certificate material is deposited into a well known and predicable location (/conf/acme/$domainHere/)

Reading through this and #2627, it looks like opnSense does not support acme.sh hooks and uses configd hooks instead. That's a bit less intuitive but I did figure out the plumbing required to register my own shell script with opnSense and have it executed after the certificate has been issued.

Unfortunately, the configd hooks don't support / pass along the usual env vars/args that acme.sh hooks get nor is the certificate material location well known / deterministic: /var/etc/acme-client/certs/6240ae5312b215.12345678/ versus /var/etc/acme-client/certs/someCertPrimaryName.com/

I can adapt my current scripts to work with DEPLOY_SSH_REMOTE_CMD but I wonder about the scalability. Is it possible to make a simpler modification to the plugin as a whole so that the path to the key material can be passed to any configctl command? This would allow users to create their own deployment systems beyond what is possible with $setOfHooksACME.shSupports intersect $setOfHooksThatPluginSupports; E.G.: update the TLS certificate used by IPMI system with something like this: https://gist.github.com/HQJaTu/963db9af49d789d074ab63f52061a951

[fraenki]

Running remote commands will be possible when #2904 is merged.

[kquinsland]

Running remote commands will be possible when #2904 is merged.

Which is good news and does solve the "remote ssh" problem. Should I create a new issue for the general "there does not seem to be a way to pass the path on disk to an arbitrary configd service" issue? The IPMI example is representative of one of the other targets that I currently have pfSense sending certs to. In that case, It isn't feasible to put the IPMI script on the IPMI host itsself to then use the ssh remote cmd trick.

[fraenki]

@kquinsland AFAICT, your request is beyond the scope of this issue, so it would be better suited in a new issue.

[fraenki]

Running remote commands will be possible when #2904 is merged.

#2904 was merged, so this will be available in the upcoming os-acme-client version 3.10.