Easiest will be to disable ssl on discourse side and let cloudflare manage ssl for you but that’s not okay at all times.
What I’ve done in my case is that I run discourse behind an nginx reverse proxy with letsencrypt ssl (in dns-01 with cloudflare dns plugin) and that makes it so that:
discourse (sockets) > nginx (ssl) > Cloudflare (ssl) > Public
Ok, step one to do this involves temporarily unchecking the orange cloud and bypassing Cloudflare entirely. To issue the initial certificate Let’s Encrypt needs direct communication with your server.
Ensure that in your app.yml the following lines are uncommented:
and add this one:
There’s little to no risk in doing this, so click on the orange cloud to disable CloudFlare, configure Let’s Encrypt. When your site is working again under HTTPS you also need to make a change within Discourse enabling the force_https setting under /admin.
Once your server is communicating via HTTPS you can change one more setting at Cloudflare if there are no other sites or applications under the same domain. Visit the ‘Crypto’ tab at Cloudflare and swap SSL from ‘Flexible’ to ‘Full (Strict)’.
Note that certain CloudFlare features are incompatible with Discourse, you’re going to need to create the following page rule:
I don’t understand how is it not easy?
If someone is just starting out, not filling in the letsencrypt email disables ssl
And once You’ve got cloudflare proxying everything and managing ssl, pretty much all that’s left is to create a page rule and disable performance.
Whether you encapsulate the traffic in SSL at Discourse, a reverse proxy, or via Cloudflare, Force_HTTPS needs to be enabled. In the scenario where the server talks to CF over :80 that means that any time you access the server directly (and bypass cloudflare) you’re using Discourse with Force_HTTPS enabled while HTTPS isn’t present.
Enabling HTTPs is easy, the only thing which defeats the process for CloudFlare users is the need for direct server communication during enrollment for the challenge to go through, which is also easy. It leaves the server in a consistent state whether the CF proxy is enabled, or not. There’s no inconsistency in behavior - which your suggestion would create.
And adding a reverse proxy is many orders of magnitude more complex.
Nobody would be here wanting to deploy cloudflare for the sake of simplicity. General implication is to increase the security bit or to use cloudflare on the rest of the website while still being able to host discourse on a subdomain (however in this case, gray cloud is the best) But there are the fanboys and you absolutely totally gotta do something for the fanboys.
Again, I disagree, CloudFlare is oft misunderstood and sold as a magic bullet for server security, which is why I see so many customer deployments with Cloudflare present and not a shred of hardening done to the local server. The perception is that you turn on CloudFlare and the rest is taken care of.
So in that case simple both describes perception of the product, and also those making the decision :D.
I had my own horror stories with trying to use cloudflare on Discourse so I just keep them totally unrelated. Managing your own server puts you into a very different perception than that of the end user who is scared of ssh.