Can acme.sh deploy certs to more than one FRITZ!Box router?

acme.sh is an excellent Let's Encrypt client, however, the documentation for it is rather sparse and does not do it justice.

I have a working VPN connection between two FRITZ!Box networks. The FRITZ!Box on the local network has an FQDN of fritzbox-l.udance.com.au and an IP address 10.1.1.1. The FRITZ!Box on the remote network has an FQDN of fritzbox-r.udance.com.au and an IP address of 10.1.2.1.

I happened to stumble across an acme.sh deploy hook that will allow me to deploy a cert to a FRITZ!Box router. I have it working. It works a treat.

I have an acme.sh server that is responsible for deploying certs to various devices. It runs in a FreeNAS jail.

# acme.sh --version
https://github.com/acmesh-official/acme.sh
v2.8.8
# freebsd-version
12.2-RC3

The local and remote FRITZ!Boxes are visible to this server. I'd like to use the server to deploy certs to both FRITZ!Boxes. However, I'm not sure if this is possible?

The documentation at deploy a cert to a FRITZ!Box router indicates that environmental variables for the deploy hook are stored in $HOME/.acme.sh/account.conf. However, it appears that only one router can be accommodated.

Cloudflare is my DNS provider. The steps to issue and deploy a cert to the local FRITZ!Box router:

# Issue cert
acme.sh --issue --dns dns_cf -d fritzbox-l.udance.com.au
# Deploy cert
setenv DEPLOY_FRITZBOX_USERNAME "basil"
setenv DEPLOY_FRITZBOX_PASSWORD "alakazam"
setenv DEPLOY_FRITZBOX_URL "https://fritzbox-l.udance.com.au"
acme.sh --deploy -d fritzbox-l.udance.com.au --deploy-hook fritzbox

This is what's written to account.conf:

DEPLOY_FRITZBOX_USERNAME='basil'
DEPLOY_FRITZBOX_PASSWORD='alakazam'
DEPLOY_FRITZBOX_URL='https://fritzbox-l.udance.com.au'

I'm assuming that the acme.sh cron job, that's automatically installed during acme.sh installation, takes care of renewing and redeploying the cert every 60 days.

24 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" --config-home "/config" > /dev/null

What's not clear though is how I accommodate a second router, if it is at all possible? For instance, using the --accountconf switch, can I use a second conf file to store the credentials for the second router? If so, what might the issue and deploy commands look like for the second router? Will auto-renewal of the cert for the second router still work? These were questions I had hoped to find answers for in the acme.sh wiki, but I haven't come across anything useful. I'm hoping there are forum members, who are more familiar with acme.sh than I am, who can shed some light on what I'm grappling with.

1 Like

Hi @basilhendroff

I don't use acme.sh (and I have only one FritzBox, the included certificate is enough).

But checking that documentation your conclusion may be incomplete.

After the first deployment, these values will be stored in your $HOME/.acme.sh/account.conf. You may now deploy the certificate like this:

acme.sh --deploy -d fritzbox.example.com --deploy-hook fritzbox

says: Export the variables of your first FritzBox, deploy it, export the variables of your second FritzBox, deploy it.

The account.conf may have only one set of account informations. But you can overwrite that with the next set of account informations.

Or check if you can create two different account.conf - files.

3 Likes

Not sure if there is "proper" way, however when i wanted to deploy my certificates on extra linux box (i assume fritzbox is runing somekind of linux/unix) i created this bash script, it uses scp (so you need to have ssh + correct key for autologin).

#function upload_cert {
#       MAX_RETRIES=6
#       i=0
#       while ! $(scp -rq /etc/acme-sh/domain.net root@host.domain.net:/etc/acme-sh > /dev/null 2>&1); do
#               i=$(($i+1))
#               if [ $i -eq $MAX_RETRIES ]; then
#                       mail -s "RSA certificate updated, ERROR with uploading to host!" root@domain.net < /dev/null > /dev/null 2>&1
#                       return 1
#               fi
#               sleep 1800
#       done
#       ssh root@host.domain.net /root/scripts/run_on_rsa_cert_renew
#}
#upload_cert &

this is a snippet from a larger reload script, what it does is it uses scp to upload local acme-sh/domain.net folder to remote location, if it fails it trys for 3hours (6 trys every 30min), if it fails you get a mail, otherwise it executes script on remote host to restart services

2 Likes

Yes, but you will need to use --accountconf parameter everytime to --issue a new cert and then --deploy it again. all the variables are stored in the new account conf file.

And, the default cronjob is only able to process default account conf.

you will need to add a new cronjob with the --accountconf parameter, like:

24 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" --config-home "/config"  --account-conf "/path/to/new/account.conf"  > /dev/null
4 Likes

It will be easier to create a new user, like useradd acme2, and then install acme.sh as user acme2, and issue/deploy it there.

5 Likes

Thank you for the clarification @Neilpang. I'll set up another acme.sh server on the second subnet to achieve this. Thank you to everyone else who contributed ideas as well.

A tip for other FreeBSD users wanting to use the acme.sh FRITZ!Box deploy hook: The FreeBSD equivalent of md5sum is md5 (more info here). deploy/fritzbox.sh needs to be tweaked slightly sed -i '' "s|md5sum|md5|g" ~/.acme.sh/deploy/fritzbox.sh for it to run successfully on FreeBSD and FreeBSD embedded systems such as FreeNAS.

2 Likes

@Neilpang Will an upgrade to acme.sh overwrite any modifications made to deploy hooks (such as in the previous post)? If so, then I should avoid auto-upgrading.

2 Likes

Yes.
I would recommend you enable auto-upgrading, since there may be bug fixings.

you can copy the deploy hook file and rename to your own name.

4 Likes

The tweak is no longer necessary. The deploy hook now works on FreeBSD without modification. Refer to this recent acme.sh commit remove dependency to md5 and awk

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.