I touched on the port 80 requirement in the github project where I said:
Successful certificate renewal via the /usr/builtin/bin/certificate binary is dependent on a web service listening on the NAS on port 80. Yes port 80 needs to be permanently open to the NAS and a web server needs to be running on the NAS listening on port 80 at all times (typically apache on an Asustor NAS) in order for certificate renewal to succeed. This is a security risk.
I strongly suspect that this only works on port 80.
The
Asustor "college" article which as far as I can tell is the only documentation available does say the following in section 3.2 Getting a certificate from Let's Encrypt:
Step 1: "Log in to ADM, select [Services]à[Web Server] and select the [Enable Web server] checkbox. Make sure to use the default port 80. Do not check the [Enable secured Web server (SSL)] checkbox." ..and this
Step 7: "[Update automatically when certificates expire.]: Let's Encrypt issued certificates will expire after 90 days. By selecting this option, ADM will automatically renew the certificate before the expiration date, if domain verification is successful. Please ensure that your NAS and router have port 80 opened in order to allow for certificate updates."I am able to say that I have been able to reliably reproduce certificate renewal failure by closing port 80 to the NAS.
Keeping port 80 permanently open with a webserver (apache) permanently listening on port 80 on the NAS is a major security concern for me. It's also concerning that Asustor are publishing this as acceptable behaviour.
I suppose it "might" be possible to run apache on some port other than port 80 by tweaking the configuration in /volume0/usr/builtin/etc/apache2 however this is not documented by Asustor in their certificate management article and goes against what they do say so it would not be officially supported and I honestly have no clue if successful certificate renewal would occur with apache running on some port other than port 80.
Furthermore the ADM /usr/builtin/bin/certificate binary that is responsible for certificate creation and renewal is undocumented and poorly supported. I've asked Asustor support for details about this binary and I struggled to get much of any substance from them at all.
Personally I'm not comfortable trusting something as important as certificate renewal to a process with undocumented undefined behaviour. I much prefer to go with certbot because it is open, well documented and more fully featured.