Avatar, Site Logos, and Cert Errors


I’ve setup Discourse servers in a about 5 instances now and all seem to be exhibiting odd behaviour; not sure if it is indeed a Bug or if anyone else has experience same.

Steps to Recreate

  • Server setup goes smooth
  • Wizard walk through is fine, all images are uploaded and shown as expected
  • User receives signup link, clicks to follow, and registration all goes well
  • (Here’s where things go sideways) User logs in and site logos are all broken – only showing text titles
  • User cannot upload/assign custom Avatar
  • Site certificate complains that site is not secure
  • For some reason this ONLY affects the browser used to sign-up, and has a much higher failure rate in Chrome


  • We’ve tried telling users to flush browser cache and cookies – still broken
  • We’ve asked users to reinstall browsers, mostly Chrome – still broken
  • We’ve asked people to use an alternative identity in Chrome or try a different browser (Safari, Firefox, etc.) – works!

We have absolutely no idea why the last item works and why the originating signup identity is messed up. It would not be tenable to ask allow our users (about 6-700) to sign out of their Chrome identity and sign back in – if, for some reason that is indeed the solution.

Any ideas?


Is it a standard 30 mins installation? Or anything custom here?

Did you enable force_https in the site settings to see if that fixes the issue?

I can’t repro your steps in my sandbox on latest branch so it’ll be really helpful if you could share link to one of the affected instances.

Hi Bahnu–

  • Standard 30 min install
  • Nothing custom
  • Have not enabled force_https but as I said, this issue only affects the browser used to register

Try enabling force_https I’m 99% sure that it’ll solve this for you.

1 Like

Okay. All install instances receive their cert from a reverse Nginx proxy that IS NOT the same machine. Will force_https still make a difference?

So that’s not a standard install. You said it was one.

If discourse is behind a Properly Configured reverse proxy, force_https will definitely make a difference. The setting essentially tells discourse to load all resources and assets over HTTPS

Alright, my apologies.

So, are we talking about force_https under app.yml or my Nginx server block?

I’m already passing though traffic properly–but I don’t see the property in the yml file.


force_https is a site setting that you need to enable in admin area.

Will it potentially lock me out?

Unless your reverse proxy is configured incorrectly, there is absolutely nothing to worry about here.

If you’re not sure about the reverse proxy configuration, take a look at this config and match it to yours

It did, btw. Lock me out. Enabling force_https fixed the image issue BUT made it impossible to authenticate from browsers with a new session. Existing session fine, but the second you log out you cannot get back in.

That’s something wrong with your reverse proxy. You’ll have to check it’s configuration to ensure that everything is set up correctly.

Just did, I have already effectively set everything up in my server block the way that article suggests. Which is probably why sessions in alt profiles/browsers work normally after initial signup/auth.

The only element where my config differs is that I am not using templates.yml.

This is going to take A LOT more investigation.

Okay. Odd. I have not changed a thing. All images work totally fine. Period.

Still getting invalid cert on initial install browser/usr ONLY though.

That could be browser cache or misconfigured certificate. Did you get a letsencrypt ssl or some other one?

It’s LetsEncrypt via Certbot. Cert is good. I think it is browser cache.

Try registering in incognito. do you still get an error?

And one thing I’m assuming is fishy here. Are you using some kind of external authentication? ( social login / SSO etc. )

No. No external auth. Tried Incognito. No dice. Same result.
Must be something in server block. Will investigate a bit later.

mind sharing link to one such install?

Did you base your nginx config off the one listed here?

Make sure that you’re sending X-Forwarded-Proto.