Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My web server is (include version): Apache/2.4.29 (Ubuntu)
The operating system my web server runs on is (include version): Ubuntu 18.04.3 LTS
My hosting provider, if applicable, is: n/a
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.31.0
I followed the certbot instructions and everything worked perfectly. The certs got installed and I’ve verified I get the nice lock icon and no warnings about certs. However, I’ve noticed on some public wi-fi networks (restaurants, etc.) browsers fail to connect. The browser doesn’t give a certificate error, it just says failed connection. This is interesting because in the past with my own certificate I would get the browser warning about a bad cert and would have the option to go on. Is this common?
What you are seeing is called a "captive portal." The public WiFi is trying to serve a fake response for the first website you visit, in order to get you to log in. However, it can only do this on HTTP sites, not HTTPS sites. When you're seeing this problem, I'd recommend navigating to an HTTP site, like http://example.com/. Then you should get the log in page for the WiFi.
Normally this is a result of adding the "Strict-Transport-Security" header, but it looks like your site is not currently sending that header. I'm not sure why you'd be seeing this.
The behavior i’m seeing with the connection failing happens after connecting to whoever’s public network. Meaning, I have already been directed to their portal login page, have agreed to their policies, and can browse freely to other sites. After this, going to my site with the letsencrypt key doesn’t work. No error message from the browser, it’s not complaining about the key, browser just gets a connection failed/refused something like that.
I only access via https. And yes I’m sure that i’m using https when attempting to connect.
I temporarily enabled port 80 in order for certbot to complete and do it’s thing. But I don’t want any 80 traffic so I disabled it again after certbot got my certs created.
I actually recommend leaving port 80 open as a redirect to port 443 (HTTPS). This is how most major websites do it, even when they've fully migrated to HTTPS. There's no harm in it, and it helps browsers find the correct version of the site in case someone forgets to type the https: at the beginning. I've written a documentation page explaining in more detail: Best Practice - Keep Port 80 Open - Let's Encrypt.
This is not very useful, but it shows the issue. The screenshot clearly shows an https connection, however, the wi-fi i’m connected to doesn’t seem to allow the connection at all. I am 100% sure the server is running, accepting connections, and successfully connect with the letsencrypt certs because I get a valid browser lock icon without any cert warnings. But some wi-fi won’t allow the connection.
Perhaps the wi-fi connections are using some kind of censorship software and your site (or ddns.net names in general?) is on the blacklist. Can you find another ddns.net site that normally works for you and see if it’s also affected on the same wi-fi networks?
