[image]How to install discourse without ssl? ./discourse-setup will serve http pages if you don’t provide an email address for let’s encrypt I don’t think that’s the case anymore. https://github.com/discourse/discourse_docker/commit/026a664e77844c7b0d67a5609f08e67f1e436d5f

Exactly @jomaxro. That is why I said [image]How to install discourse without ssl? Yes, but that requires not using the ./discourse-setup script and editing your app.yml manually.

Oh. Sorry. I missed that change. So if the user does not provide a let’s encrypt notification email address, discourse-setup now blindly enables let’s encrypt without verifying that the domain resolves to the current server. But if you do provide an email address then it does the check. This doesn’t seem like a very good idea. Why force https when they don’t have a valid domain name? If the plan is to force everyone to use https all the time, then we should test if the domain name is valid and then refuse to run rather than give them a broken install. The way that it works now, if you don’t provide a let’s encrypt email address and the domain doesn’t resolve to the server then discourse-setup appears to succeed, and it cranks up a web server that won’t accept connections because nginx can’t find a certificate. I think a better thing to do is to not ask for a let’s encrypt email address, use the (first?) developer email for let’s encrypt and still do the DNS test, but now this doesn’t belong in this topic.

[image] pfaffman: now blindly enables let’s encrypt without verifying that the domain resolves to the current server. But if you do provide an email address then it does the check. No that’s not how let’s encrypt works. The email has nothing to do with domain validation. It’s used to alert the user if their certificate is due to expire and can’t be renewed. Validation is always done by DNS. Let’s Encrypt can’t issue a certificate for an address which doesn’t meet the requirement for validation. If it did then the whole LE scheme would implode overnight.

[image] Stephen: No that’s not how let’s encrypt works. No. It’s how discourse-setup works, or used to. It used to protect users from requesting a certificate when it was pretty sure that it would fail. Now, it’ll move ahead, request a certificate when it can’t possibly succeed, and not have any way of reporting to the user that it didn’t work, so it now fails silently with no warning.

Again, why would it fail? Email isn’t a requirement for domain verification. Failure never generated an email either. The email is only there to tell the user later on if Let’s Encrypt is failing to renew and a cert is due to expire. If the cert renews without problem they’ll never see an email.

[image] pfaffman: blindly enables let’s encrypt without verifying that the domain resolves to the current server I don’t think that was the intent of the change. The intent was to enable SSL regardless of if an email is provided. We should still check the domain resolution cc @Falco

It will fall if the domain name doesn’t resolve to the host. The email address doesn’t matter, but if there is one Discourse setup will warn the user if the address doesn’t resolve.

Domain resolution must pass @falco, otherwise setup should halt.. this is a bad change.

[image] codinghorror: Domain resolution must pass @falco, otherwise setup should halt So I made some changes in a branch. Here is how it is going to work: Using a wrong hostname: root@droplet:/var/discourse# ./discourse-setup Hostname for your Discourse?: bad-domain.com Checking your domain name . . . WARNING:: This server does not appear to be accessible at bad-domain.com:443. A connection to http://bad-domain.com (port 80) also fails. This suggests that bad-domain.com resolves to the wrong IP address or that traffic is not being routed to your server. Google: "open ports YOUR CLOUD SERVICE" for information for resolving this problem. If you want to proceed anyway, you will need to run cp samples/standalone.yml containers/app.yml and edit the containers/app.yml file manually. Using a correct hostname: root@droplet:/var/discourse# ./discourse-setup Hostname for your Discourse?: good-domain.com Checking your domain name . . . Connection to good-domain.com succeeded. Email address for admin account(s)? : Changes are pending at Early hostname check (#456) master ← early-hostname-check opened 05:36PM - 19 Feb 20 UTC (UTC) [image] xfalcox +5 -10 Does it looks good @pfaffman @codinghorror ?

Commentary on why this change was needed in the first place First, I’m surprised that in the nearly 3 months since this has been this way there haven’t been lots of complaints, and even the topic that brought this to my attention wasn’t having trouble because of this change, so maybe it matters much less than I think. The first thing that I don’t really understand is, you guys really want to make it so that it’s impossible to set up an http-only site with discourse-setup? I guess they have to have done a bunch of DNS stuff to make mail work already, so maybe it’s not that big a problem to have them create the A record too. Feedback on the change Unless you made a change that I haven’t noticed, the script creates app.yml before it starts asking questions, so you could just say something like “Discourse installation without DNS configuratoin is not supported. To continue without DNS configuration, edit app.yml to suit your needs and run ./launcher rebuild app” and then quit without bootstrapping. Also, if you’re going to enforce everyone-has-to-use-let’s-encrypt-and-https, then it might make sense to change standalone.yml and web_only.yml accordingly and then those fiddly sed statements could be removed. More musings From the this-is-my-problem department, my current install script runs before people can set up DNS, as I create the droplet for them, set up Discourse, send them an email with DNS instructions, wait for DNS to be set up, and then modifies app.yml to enable the templates and set the let’s encrypt address. But I guess that’s just for historical reasons, what I should do instead is create the droplet, configure mailgun, wait for DNS, then do the installation, that would still let my script use discourse-setup, which I like doing as a frequent test that it’s still working (I don’t think that you guys are doing an automated test of discourse-setup are you?)

Discourse setup script hostname validation for Let's Encrypt

Development

Falco (Falco) February 19, 2020, 7:29pm 14

Cool, thanks for the analysis and review!

Merged the PR so we will always validate DNS now.

Topic		Replies	Views
Set up HTTPS support with Let's Encrypt Self-Hosting how-to , domains	2	111699	February 25, 2024
Installed without error but site wont come up Self-hosting	12	2035	February 13, 2017
No connection accepted on http / https after fresh installation on Ubuntu 22.04 LTS Self-hosting	5	2601	December 16, 2022
After Discourse installation can’t reach it in browser Self-hosting	24	4371	September 5, 2020
Using a certificate when Discourse is installed behind a reverse proxy Self-hosting unsupported-install	24	5377	May 17, 2019

Discourse setup script hostname validation for Let's Encrypt

Related topics