When setting up a new Discourse forum, I recently forgot to enable the force https setting 
This isn’t just a security issue, it also prevents internal HTTPS links from getting the onebox treatment.
Because this setting should usually be enabled anyway, I’d suggest that the setup wizard should prompt to enable it, at least if the user is viewing the wizard over HTTPS. (In that case, I’d even consider enabling it without prompting…)
I suppose if they have HTTPS working already it wouldn’t harm to turn it on. I am afraid of users turning it on if they haven’t set it up properly yet as their site will become inaccessible.
Maybe a careful way to push users would be this?
(For extra points: If the user doesn’t have HTTPS set up when the wizard exits, seed a system topic in the internal category with instructions for setting up HTTPS.)
This may need to wait until all our hosted sites are https-on by default… but I agree that if the wizard senses HTTPS is already on then it should be turned on.
Do I understand things correctly that force https is not necessary/irrelevant when my outer NGINX is taking care of SSL?
And if that is so, how might the suggested auto-enable feature affect such constellations?
No, you should definitely enable the site setting in these cases! It affects many things like internal link handling and whether cookies are marked as secure.
Also we can display warning in admin dashboard like above.
Are we currently displaying that warning? I agree we should if we are not!
No. Currently we are not displaying that warning. I will add.
I have been looking at this warning for quite some time, and it is starting to bug me.
What does this feature actually do? Is it documented somewhere? Are there some requirements for enabling it?
My site has been https -enabled for ages, via Let’s Encrypt.
It will mostly check that your SiteSetting.force_https == true so if you set this setting it will make the warning disappear.
I too had a fully HTTPS enabled site since forever but then this warning started to be pushed at me every week. It took me a long time to find the time to really dig into what the setting does.
I’m assuming that @ljpp is, like I was, more interested in what the force_https setting actually does rather than just knowing which magic checkbox to enable to make the noise go away.
My site has always had HTTP redirected to HTTPS so I could only assume that this setting is there to enable an HSTS header. After digging into the Discourse source code I confirmed that this is what it does and that it only affects the host name of the discourse site rather than the entire domain name.
Enabling the setting results in a header like this being included with every HTTPS response from the server:
strict-transport-security: max-age=31536000 (1 year)
I intentionally left the setting disabled until I could look at the source code because the setting isn’t documented and I was concerned that it might enable HSTS on my entire domain.
Interestingly this old Discourse PR fixed the very issue I was concerned about, although both it and this relevant stackexchange Q/A seem to interpret the HSTS spec incorrectly. If all user agents have incorrectly implemented the HSTS spec then there may have been nothing for me to worry about in the first place. I’ve recently posted a contradictory answer to stack exchange so it will be interesting to see if that triggers some authoritative confirmation of the situation from those that maintain and implement the spec.
In the mean time, I would say that if you’ve done all the usual checks to ensure your entire forum and all included content work fine over HTTPS then it is safe to enable this setting. I enabled it on my site a couple of months ago with no ill effects.