# Les liens d'invitation pour les nouveaux utilisateurs génèrent uniquement ERR\_SSL\_PROTOCOL\_ERROR
**URL:** https://meta.discourse.org/t/new-user-invite-links-only-give-err-ssl-protocol-error/103572
**Category:** Support
**Created:** [Décembre 5, 2018, 9:01 UTC](https://meta.discourse.org/t/new-user-invite-links-only-give-err-ssl-protocol-error/103572 "2018-12-05T21:01:56Z")
**Posts on this page:** 15
**Page:** 1
Hello everyone–
## Summary
New user invite links give a ERR\_SSL\_PROTOCOL\_ERROR even though the rest of the site works fine.
## Context
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](https://meta.discourse.org/t/setting-up-https-support-with-lets-encrypt/40709/97).
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](https://meta.discourse.org/t/setting-up-https-support-with-lets-encrypt/40709). Everything ran fine, and the problem persists.
The logs don’t look perfect, though:
```plaintext
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 http://www.rsyslog.com/e/2222]
Server listening on 0.0.0.0 port 22.
rsyslogd: imklog: cannot open kernel log (/proc/kmsg): Operation not permitted.
rsyslogd: activation of module imklog failed [v8.16.0 try http://www.rsyslog.com/e/2145]
Server listening on :: port 22.
rsyslogd: Could not open output pipe '/dev/xconsole':: No such file or directory [v8.16.0 try http://www.rsyslog.com/e/2039]
supervisor pid: 1099 unicorn pid: 1125
```
For the first error, I found [this post](https://meta.discourse.org/t/discourse-not-starting-up-nginx-unable-to-open-supervise-ok-file-does-not-exist/53706) 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
---
More info!
The invites get sent out with a link like `forum.mysite.com:80/invites/...` but when one removes the `:80` the links don’t have the auth error.
So why are we getting `:80` in the links?
Thanks!
---
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.
---
Well, `DISCOURSE_HOSTNAME` is exactly the name of the site as it should be.
The only place that 80 appears is in this block:
```plaintext
## which TCP/IP ports should this container expose?
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
```
Thanks!
---
I found that [https://www.phylobabble.org/latest.rss](https://www.phylobabble.org/latest.rss) has the `:80`s in the links, and then looking at the [relevant Discourse source code](https://github.com/discourse/discourse/blob/acd1693dac1bff6ff50250d942134bc48a27ff14/app/views/posts/latest.rss.erb) I see that it’s being directly put in the RSS via
```plaintext
<%= @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.
---
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?
---
I can’t find anywhere that we might be explicitly setting the port anywhere. And to clarify from Erick’s post above, `DISCOURSE_HOSTNAME: www.phylobabble.org`, 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 · GitHub](https://github.com/discourse/discourse_docker)
```plaintext
templates:
- "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
---
You are following our [official install](https://meta.discourse.org/t/142537?silent=true) 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.
---
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 `phylobabble.org:80` requests to just `phylobabble.org`? We tried mapping ports like so:
```plaintext
expose:
- "80:22"
```
which didn’t make a difference.
---
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. 🙇♂️
---