Let's Encrypt module, improve documentation?

#1

When setting up Let’s Encrypt, I ran into a failure that was only resolved when port 80 was forwarded through my router’s firewall. I only had port 443 forwarded when I initially attempted to obtain the certificate.

Once port 80 was forwarded through the firewall, the certificate was obtained successfully.

Is it presumed that ports 80 and 443 should be forwarded to the Web server? After the certificate was successfully setup, I closed port 80 at my router as it doesn’t serve a purpose in my opinion.

It seems like this should be mentioned in the “Learn more…” link in the Let’s Encrypt module page.

A bit off topic, should an option exist to enable an automatic redirect from port 80 to port 443?

I am running the current Freedombox image provided by Olimex with the Pioneer HSK I received last week.

#2

I thought Let’s Encrypt would try port 443 and allow an invalid certificate on it if it tries with port 80 fails. I guess that only happens when there is a redirect setup.

Looks like this was mentioned in wiki page https://wiki.debian.org/FreedomBox/Manual/LetsEncrypt (which is the source for the Learn More link). Please feel free to edit it with more info.

I believe this should be the case. I guess we were being a bit conservative since HSTS is enabled, a redirect cause issues when the certificate is invalid. I created an issue to track this: https://salsa.debian.org/freedombox-team/plinth/issues/1586

#3

Indeed both ports 80 and 443 are documented. I’m not sure how I missed that. Perhaps a note that Let’s Encrypt requires port 80 for initial setup until a redirect is in place, etc. would have proved helpful. I’ll consider that a bit before adding it to the Wiki.

1 Like
#4

I looks like port 80 will be needed even after the initial setup for future renewals. After the redirect is setup and the LE is in good shape when LE is trying to renew a certificate it will first look at port 80, get redirected then look at 443 (even if the certificate is expired or invalid). However, if port 80 is closed, it may not try on port 443 at all. At least this is what I gather from the problem you have faced.

#5

While securing each Web app is an excellent idea, I think it would be useful to provide an option to provide secure transport for all pages including user pages and pages under /var/www/html (the default document root) if that is set to be served as the default rather than plinth.

I see you’ve already noted this in the issue tracker. Sorry for the noise.