Sophos Utm Certificate Renewal
Florencia Abila
A XGS runs a Linux Kernel 4.14 and allows ssh login and a real shell via 5. Device Management -> 3. Advanced Shell. We figured this could be used to run the required programs. We decided to use the excellent acme.sh client to try to get a working http acme process and then see if we can use this to get a working setup.
Our initial reaction was to disable the http to https forwarding and add iptable rules to get the packets to our python webserver running on port 80. But we could not figure out which rules that are responsible for dropping those packets and it was quite ugly approach as it required to deactivate the http to https redirection.
The storage path problem was solved quite easily but just creating an acme folder in /config/ and reboot the firewall to test if our folder was still there, as it was after a reboot so we moved to the next problem.
Running a script everyday on a linux machine is usually done by cronjob or a systemd timer. Both mechanisms are not available on a Sophos XGS. So we tried the little more obscure command at which was also not available. So we opted to use a while loop with sleep to run every day. Which solved the timing problem, but we still needed something in the system to start our script after each reboot.
As the sophos xgs is a busy box system rc.d init scripts are supported and after mounting the root file system read/writable we where able to add a short script to it S01acme which just launches our renew.sh and does not wait for completion. After we where done we switchted the root filesystem back to read only.
Currently the expiry stats in the sophos webinterface are not updated after a certificate is renewed. If we find out where those information is stored this could be updated as well. Or handeld via the sophos firewall api
I also noticed that my Calenders and Contacts refuse to sync with my phone. Access denied error. My nextcloud itself runs fine though. I have checked the .well-known locations, but that are mentioned in nginx.conf. And nothing should have changed there correct? Any hints are appreciated!
I have forwarded port 80 on my router (as it has been for over two years). When I go to my site via http I am redirected to https. Works fine. I did not change anything on the server where Nextcloud is running, nor did I change anything on the Nextcloud config itself.
I really do not think this is a matter of the port not being open. I have tried placing a text file in the /var/www/letsencrypt/ to see if I can open that via http, but I have no clue what the url would then be. Something like -known/acme-challenge/ ? That seems to simpy redirect my to my nextcloud home
Usually, with 80 and 443 TCP NAT-ted towards the internal IP of your instance (fitting with the configured hostname) everything should work, mostly the error is something not directly connected to your Nextcloud.
If you where to take a look at how certbot works you would see that it places a challenge/key in the directory that is specified when it tries to renew a certificate. That is to make sure that the dns is still pointing to the correct webserver. Works much the same as the dns challenge, except the key is stored on your webserver, not your dns server.
Alright, I just found out what caused the issue. Although I do not understand how that worked out. The VM that was running Nextcloud was using a bridged adapter. However, there where no physical interfaces available to bridge to since they are all in use by my firewall/router.
The bizarre thing is that I only found out after I noticed that the network card was disconnected after I rebooted the host. I could not reconnect it, the binding failed. Before that however, I could still reach my site and it was using the correct IP. But for some reason the certificate renewal failed.
So I am still not sure why the problems with the virtual network caused such weird issues and why it was at first still working even though VMware told me that there was no available interface after I edited the VM. But I am sure that this is wat solved the issue. I am guessing some kind of cache in VMware Workstation pro that still bound the VM to the correct interface, eventhough that was now assigned to a different vmxnet.
4a15465005