New user invite links only give ERR_SSL_PROTOCOL_ERROR

(Erick Matsen) #1

Hello everyone–


New user invite links give a ERR_SSL_PROTOCOL_ERROR even though the rest of the site works fine.


I’ve been running a completely stock Discourse Docker image for about 5 years with no troubles. About a year ago I moved to https with Let’s Encrypt using this guide.

Since then the site has performed well, and existing users can log in and out.

Problem and troubleshooting

As described, new user invite links give a ERR_SSL_PROTOCOL_ERROR even though the rest of the site works fine.

I have run all of the debugging steps in the Debugging section of the Discourse Let’s Encrypt setup guide. Everything ran fine, and the problem persists.

The logs don’t look perfect, though:

warning: nginx: unable to open supervise/ok: file does not exist
[Wed Dec  5 20:41:53 UTC 2018] Reload error for :
Started runsvdir, PID is 1086
ok: run: redis: (pid 1101) 0s
ok: run: postgres: (pid 1096) 0s
rsyslogd: command 'KLogPermitNonKernelFacility' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try ]
Server listening on port 22.
rsyslogd: imklog: cannot open kernel log (/proc/kmsg): Operation not permitted.
rsyslogd: activation of module imklog failed [v8.16.0 try ]
Server listening on :: port 22.
rsyslogd: Could not open output pipe '/dev/xconsole':: No such file or directory [v8.16.0 try ]
supervisor pid: 1099 unicorn pid: 1125

For the first error, I found this post but I am not using a proxy.

Has anyone else run into this problem? I run another site, started a little later, which does not show this problem.

Thank you!


(Erick Matsen) #2

More info!

The invites get sent out with a link like but when one removes the :80 the links don’t have the auth error.

So why are we getting :80 in the links?


(Jeff Atwood) #3

Sounds like you have a bad configuration? What is in your app.yml as far as domain name?

Discourse does not support being run on alternate ports.

(Erick Matsen) #4

Well, DISCOURSE_HOSTNAME is exactly the name of the site as it should be.

The only place that 80 appears is in this block:

## which TCP/IP ports should this container expose?
  - "80:80"   # fwd host port 80   to container port 80 (http)
  - "2222:22" # fwd host port 2222 to container port 22 (ssh)
  - "443:443" # https


(Erick Matsen) #5

I found that has the :80s in the links, and then looking at the relevant Discourse source code I see that it’s being directly put in the RSS via

    <link><%= @link %></link>

so Discourse definitely thinks that my site ends with :80 as suggested, and it’s not some weird DNS problem or something.

I can’t find anything via grepping in /var/discourse that looks out of order.

(Christopher Small) #6

I think you may have the wrong line @ematsen. I think the broken link is on a line a bit lower down (#15):

Looks like the issue may be Discourse.base_url. @codinghorror Is there somewhere we haven’t looked at wherein that might be getting set/modified?

(Jeff Atwood) #7

You should not be explicitly setting a port anywhere, that is for sure.

(Christopher Small) #8

I can’t find anywhere that we might be explicitly setting the port anywhere. And to clarify from Erick’s post above, DISCOURSE_HOSTNAME:, which seems as it should be.

I thought for a while that maybe one of the templates getting loaded might be causing the issue, but these should all be exactly as we found them in the discourse docker. For the sake of thoroughness, here are the templates we’re using, all of which should match those here: GitHub - discourse/discourse_docker: A Docker image for Discourse

  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/sshd.template.yml"
  - "templates/web.ssl.template.yml"
  - "templates/web.letsencrypt.ssl.template.yml

I tracked down where this Discourse.base_url that pops up in the RSS feed might be coming from and it looks like it’s defined here:

Which is in turn defined based on base_uri, defined here:

I can’t figure out how either of these would be coming out wrong though. My next thought is to litter that discourse.rb file with print statements to see what’s going on, but any help you could provide in helping us track how those values are being computed would be helpful in us narrowing in on where things are going wrong.

Thanks in advance

(Jeff Atwood) #9

You are following our official install guide to the letter, yes? This isn’t a problem we see often (or at all, honestly).

Did you do a developer type install where you explicitly overrode the port? That’s only done on developer installs to my knowledge.

(Erick Matsen) #10

I did follow the install guide to the letter, and the site’s been running beautifully for many years now (thanks!).

I did the most vanilla type install I could do-- definitely not a developer install.

As a crutch, can you think of a way to forward the problematic requests to just We tried mapping ports like so:

  - "80:22"

which didn’t make a difference.

(Rafael dos Santos Silva) #11

Can you share the output of:

cd /var/discourse
./launcher enter app
rails c

(Erick Matsen) #12
[1] pry(main)> SiteSetting.port
=> "80"

(Rafael dos Santos Silva) #13

Try to clear it please:

#everything above and then
SiteSetting.port = ''
./launcher restart app

(Erick Matsen) #14

That did it! Thank you so much, @Falco and @codinghorror. I really have been amazed how smooth the admin process is, and Discourse itself is lovely. :bowing_man: