On 12/13/21 2:14 AM, Michael D. Setzer II via users wrote: How are people reaching your server? By IP or with a hostname? If you have a hostname, on a "real" domain (not your ISP provided name), you have two options: - you should have DNS control for the domain, so you can use DNS verification with certbot instead of http - you may point your domain on another (not firewalled) IP, answer the certbot challenge on port 80 and then switch back the DNS andinstall the cert you have obtained on your original IP; surely that is annoying to be repeated at every cert renewal Regards. -- Roberto Ragusa mail at robertoragusa.it

On 12/13/21 1:27 PM, Michael D. Setzer II via users wrote: Unfortunately you don't have an easy solution. Missing port 80, 443 and DNS control rules out all the official supported ways. https://letsencrypt.org/docs/allow-port-80/ Only things left are: - point your dyndns temporarily to another (collaborative and trusted) IP that will complete the verification (annoying renewals every 90 days) - stop trying to get a CA-issued certificate, and just create a self signed cert (still better than nothing, depending on who your users are) Regards. -- Roberto Ragusa mail at robertoragusa.it

On Mon, 2021-12-13 at 12:45 -0700, Greg Woods wrote: While it can do what you want, it is subverting the purpose of HTTPS. I'm not sure anyone should support a technique that hides an insecure connection behind a faked secure one. Really, such security holes ought to be fixed so they aren't a security hole. -- uname -rsvp Linux 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.

Tim: Greg Woods: In the sense that if you can do it, miscreants can. We should be endeavouring so that browsers can't be fooled, and thereby their users. And some will argue that means disallowing overrides. e.g. How many Windows users just clicked away the allow/deny pop-ups that were supposed to protect them? If you make things so your browser doesn't warn you that you're about to do something unencrypted when it otherwise ought to be, you can be setting yourself up for an exploit in the future. But from following up on what's been previously written in the thread, it sounds like something is erroneously triggering the use of HTTPS, and that's the real problem. It could be how dyndns.org is handling redirecting connection attempts through their domain to their IP. I run an externally hosted website, and I peruse the logs and see various failed attempts to do something being logged. In my case, their exploit attempts, not genuine browsing going wrong, so I do nothing to help those failures. -- uname -rsvp Linux 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.

On Wed, 2021-12-15 at 00:37 +1000, Michael D. Setzer II: If they don't advertise it as static ("that's a feature!") it probably isn't. It's highly likely that they set the lease on the IP with a reasonable time period so that you're going to get the same IP if you temporarily disconnect for a short period. You may get the same one if you disconnected for a longer period, but there's probably some time period where you lose the lease and get a different IP. At one stage my ISP would give you the same one unless you disconnected for quite a lengthy period, now it's only a few minutes. I suspect that may be due to how they tell customers who complain about network faults to reboot and reset everything, and hope that by the time they reconnect they end up with a different address that goes slightly different through their network, and the fault goes away (for that customer) without the ISP actually having to do anything. Common enough with cheap or free certificates. You generally have to pay to get a pre-approved one. Many ISPs block customers running services. They'll either charge extra for the feature, or simply don't want to deal with the headaches that badly managed servers can wreak. 443 is the only standard port used for HTTPS. Although some nerds may suggest that 8443 is an alternative HTTPS web browsing port, it is not. The numbers don't suggest purpose (i.e. something with 443 in it, somewhere, is not HTTPS because of those numbers, and something starting with 8 is not web-related because of those numbers). While computer users might like to pick them for human-obvious reasons, there's nothing even semi-official about it. As with port 80, ISPs do various things to other common port numbers, to allow or deny services for their clients. You can try non-standard ports, they may allow them through, web-browsers may allow them. See how your browser fares trying to connect to other ports internally, then you can try using them externally. You might have to go higher up. But some ISPs inspect packet content, regardless of port, and will mess up any kind of HTTP traffic coming into you (which also can disrupt things like file transfers in instant messengers, ICQ, MSN, Jabber, and others, since they often use the same hyper-text transfer *PROTOCOL* to do the work). There are lists of well-known and registered ports. They don't absolutely reserve ports for specific functions, but traditionally certain services use certain ports, and can be expected to be found there. When you use other ports, you have to be able to either include them in the address, or somewhere in the configuration. And be prepared to deal with conflicts. Ports 0 to 1023 are the most well-known ports, and your own operating system networking will often require special privileges to be able to use services on them (e.g. an ordinary user can't run the mail server in their own account, on the standard mail server port numbers, it needs a server kind of account). Ports 1024 to 49141 have a lot pre-registered uses, and if I remember correctly, Linux won't restrict ordinary users from using them. Though you might have to manually twiddle firewall and SELinux rules (well, I say "might" but in a security concious installation, you almost definitely will have to manually configure something allow it). Ports 49152 to 65535 are known as dynamic, private, or ephemeral ports, with no specified use (though there are some applications which are known to make use of some of these, they're not reserved for their exclusive use). They are expected to be used at the whim of any software communicating across a network. Though, again, to run a server on them you *might* (but probably will) have to manually twiddle your firewall and SELinux rules. e.g. When you browse a webserver on port 80 (the server's port 80), your end will use one of these ephemeral ports to connect to their port 80. Depending on your OS there will be some scheme as to how it picks them. I've used far too many OSs over the decades to remember which ones do what. They might start at the lowest un-used one and work upwards, or the highest free one and work down, or pick at random (as a privacy or pseudo-security technique of making your computer's networking more unpredictable to miscreants). I'm not sure how well different OSs handle you trying to run a service on a port number that they might expect to be able to use by their choice, but a TCP/IP stack ought to be able to determine whether a port is in use by *something* and not try to double-up on it. Anything that doesn't check and just blithely assumes it can do what it wants is bound to have some kind of failures. If you were running multiple servers (web servers, peer-to-peer, etc), it'd be your responsibility to set each one up to work in different ranges. Since you're experimenting for your own purposes, there's no reason why you can't just try some random high port number and see what happens. NB: Anywhere I've said that your ISP or OS may impose restrictions on the use of port numbers, remember that your modem/router might impose its own limitations, too. If the browser has a HTTPS everywhere plugin, or built-in, feature, that could be the cause. But they really should allow a HTTP fallback when HTTPS doesn't work. Though, I suppose, even that could fail if the webserver gives some kind of initial response, so the browser doesn't try falling back. Akin to how years ago many websites complained you had JavaScript turned off if you didn't accept a cookie, or vice versa, instead of testing cookies with cookies and scripting with scripting (programmers making dumb assumptions). I'd read, elsewhere, about Google Chrome enforcing HTTPS with certain domain names (e.g. with ".dev" top-level-domains). As I've said, I'm not pleased with the HTTPS-everywhere push, it's not always appropriate, and programmers are notorious for making dumb assumptions. -- uname -rsvp Linux 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.

On Tue, 2021-12-14 at 10:09 -0600, Dave Ihnat wrote: That's a bit like saying I don't use a ruler as a rule, though all I ever do with it is rule lines and measure things. :-\ -- uname -rsvp Linux 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.

On Mon, 2021-12-13 at 11:14 +1000, Michael D. Setzer II via users wrote: I'd only go through this pallaver if they cannot make a HTTP connection. Are the logged attempts failing HTTPS and aborting, or failing HTTPS then succeeding with HTTP? I don't agree with this HTTPS everywhere thing. Some things don't need to be encrypted, and some things can't be. I wouldn't want my browser to prevent me from being able to browse some service. -- uname -rsvp Linux 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.

On 14 Dec 2021 at 0:01, Tim via users wrote: Subject: Re: Setting up webserver for https?? To: users(a)lists.fedoraproject.org Date sent: Tue, 14 Dec 2021 00:01:21 +1030 Send reply to: Community support for Fedora users <users(a)lists.fedoraproject.org&gt; From: Tim via users <users(a)lists.fedoraproject.org&gt; Copies to: Tim <ignored_mailbox(a)yahoo.com.au&gt; Not sure on that? The access_log showed the lines with code that I later found meant that it was trying to connect with https, but there was no successful links to the index or other pages after it? No messages, so don't know what the users are getting on there end?

What do you see in the log? Is it CONNECT trying to use you as a http proxy or a TLS hello? Barry