That is interesting. I proxy hypnotoad via apache2 on my servers (since I have other sites that also run on the same server), and I have port 80 redirected to port 443 as well. It works fine with that. I am not sure why it is an issue when serving directly with hypnotoad.
For a workaround you could just temporarily disable forwarding of port 80 to port 443 when you update the certificate.
Yeah, I know it isn't convenient.
My production server is still on 2.17, running Apache. I use CertBot there with the webroot option. (It took me a bit to figure out what the right for is.)
You put a file in the root folder (I think this is /var/www/html for me) and CertBot uses that for the challenge process.
I set it once and it seems to be chugging along just fine. I should probably do the same on 2.18.
Unfortunately, I don't think that the webroot option will work for 2.18 when serving directly with hypnotoad.
In order for the webroot option to work, you need to pass certbot the directory on the server that is served as the html root. Then certbot creates a .well-known subdirectory there, and a temporary file in that subdirectory. Then the Let’s Encrypt validation server makes a request to your server to get that file.
If you are serving directly with hypnotoad then no matter what directory you pass as webroot, the Let's Encrypt validation server request for the above file will fail, because the webwork2 app does not serve that file.
Oh! Thanks for saving me the trouble of discovering that the hard way.
So it sounds like my options are to either proxy by Apache and use webroot, or figure out a way to script the renewal process with hypnotoad.
(Or just have hypnotoad listen only on 443. Is there anything inherently bad about doing it that way?)
Maybe Alex Jordan found a better solution. I'll ask the next time I talk to him.
If you are using apache2 with webwork 2.18, there is no need to use webroot. You can use certbot's apache2 method. Webwork 2.18 does not cause the issue that previous versions of webwork did. The issue was mod_perl2.
There is nothing wrong with only listening on port 443. It is a convenience for your users to redirect port 80 to port 443, but not necessary. However, It can be a bit confusing for your users, if they enter a url and get taken to the unsecured port 80 and get the site is not found.
What I found is that if I am serving directly with hypnotoad, it has occupied (in some sense) port 80, and apache won't run simultaneously because of the port being in use. certbot attempts to fire up apache to do its thing, but it can't. So to use certbot, I do something like:
systemctl stop webwork2
systemctl start apache2 (or httpd)
certbot renew
systemctl stop apache2 (or httpd)
systemctl start webwork2
with a brief outage of service for webwork2. And this works. (And it's a separate issue, but the new certs may end up in file trees that are not readable by the www-data user (or whichever user hypnotoad is run by) and a follow-up step is to change ownership of some intermediate folders to those certs, and check on their permissions).
There is some documentation on this at https://webwork.maa.org/wiki/WeBWorK_2.18_Ubuntu_Server_22.04_LTS_Amazon_Machine_Image#Renewing_the_certificate
Check the permissions/owner on every intermediate folder in the symlinks that points to the certs. That was the issue for me with this. Twice now.
Right, by "hypnotoad user" I did not mean a user named hypnotoad. I mean the user that the webwork2 service is running under. Probably www-data in this case.
So you no longer have an issue? If you do still, did you check permissions on each and every intermediate directory?
Maybe not? I mean, I guess I could force an early renewal to see what happens, but otherwise, I won't know until the automatic renewal runs again in a few months.
Certificate renewal took down my server again.
New certificates are installed in the archive folder with root as the owner, and I have to chown to the www-data user to get the site back up.
Have you had any luck with automatic renewal? Or are you just setting yourself a reminder to do it manually every 3 months?
Arnold, I think these instructions need to be updated to make it clear that there's an issue with automatic renewal: the renewed certificates are owned by root, and can't be accessed by www-data. Unless there's a better way to configure things to avoid this issue, the instructions are going to need to explain how to update ownership each time (and perhaps run everything as a scheduled process for those, like me, who will forget to do it manually).
This looks like exactly the thing, thanks! I'll add any further comments over on GitHub.