CloudFront cannot establish SSL connection to Discourse origin

(Aahan Krish) #1

I am setting up Discourse using Docker, following the official installation tutorial, with SSL and CDN enabled. The installation process completes without any errors, but when I load the forum it shows up blank (white screen).

Browser console shows this:

I tried modifying app.yml like this:




  ## Cross-Origin Resource Sharing


Still the same white screen. Looks like the CORS variables are not among current env variables for Discourse.

This seems to be the fix (credit to @sam):

But it’s just a side-effect of disabling an option. Besides I don’t need to uncheck this option when I install Discourse with CDN enabled but without SSL. So, there must be something wrong with the SSL side of Discourse?

EDIT: Could this really be a bug? See:

NOTE: This question has changed substantially since it was first posted; corrected my incorrect initial understanding of the situation.

(Ben T) #2

Do you mean that the install is inconsistent with the CDN enabled? That’s a different issue than the install overall being inconsistent.

From the error you’ve posted it looks like the CORS header is not being added at the CDN level; if it was on the discourse/docker level that message would have the host names switched. In this case, that error is implying that the origin ( can not access the CDN (*** because the CDN does not have CORS headers.

Can you take a screenshot of any headers you get from your CDN (in the network tab)?

(Aahan Krish) #3

Oh, yes.

CloudFront caches the response headers from the origin. So if the origin was serving proper headers, there shouldn’t be any problem with the CDN. Besides, like I said, Discourse installs fine sometimes and the forum loads fine (with the same CDN).

Coming up. (I had deleted the Discourse instance; re-installing now…)

(Ben T) #4

How long does cloudfront cache for? Maybe it’s holding onto headers it gets back as docker is bootstraping, or something else. The “sometimes” error seems to imply that… if it was all the time that would be something different.

(Aahan Krish) #5

Good point. Will test with a new distribution and get back to you shortly.

(Aahan Krish) #6

Tried with a new distribution, and still the same. Here’s a screenshot of the header:

Not sure about the 502 Bad Gateway error on the CDN. At least I’ve got something to work on now. I’ll take another look.

(Aahan Krish) #7

This indeed looks like a bug. The reason behind CloudFront returning a 502 Bad Gateway error is probably because:


CloudFront forwards HTTPS requests to the origin server using the SSLv3 or TLSv1 protocols and the AES128-SHA1 or RC4-MD5 ciphers. If your origin server does not support either the AES128-SHA1 or RC4-MD5 ciphers, CloudFront cannot establish an SSL connection to your origin.

And Discourse’s configuration (templates/web.ssl.template.yml) doesn’t seem to support those ciphers; or does it?


But it’s weird that the setup works if enable cdn js debugging option is unchecked. Can anyone confirm whether this is a bug?

Disabling an option is not really a fix IMHO, especially because that option is useful!

(Sam Saffron) #8

This is clearly a bug, and I can see it here as well.

I have the ACCESS-CONTROL-ALLOW-ORIGIN on vendor.js, but it is missing from en.js and browser-update.js

Will have a look and get that fixed.

That said, if you are noticing a missing header on vendor.js you have a CDN issue.

(Aahan Krish) #9

Confirmed! @sam and @codinghorror: CloudFront cannot establish SSL connection to Discourse unless the ciphersuite is modified to include the AES128-SHA1 or RC4-MD5 ciphers (probably because these are faster encryptions). I am told AES128-SHA1 is more secure than RC4-MD5. Here’s the response to my question from an Amazon AWS employee:

CloudFront when forwarding HTTPS requests to the origin server uses AES128-SHA1 or RC4-MD5 ciphers and if your origin server does not support either the AES128-SHA1 or RC4-MD5 ciphers, CloudFront cannot establish an SSL connection to your origin.

It seems that your server is not supporting any of the two ciphers so most likely this is causing the issue here. Can you please enable these ciphers and try again.

EDIT: Didn’t see your earlier reply. There are two things to fix now then?

(Jeff Atwood) #10

@sam is this something we need to fix in the Docker image for v1 as well?

(lid) #11

isn’t it just a change in the nginx config?

DHE-RSA-AES128-SHA seem to be i the conf, I wonder if this is enough for cloudfront

(Sam Saffron) #12

I fixed the two problem JS files, but did not touch the ssl template. We are using the cipher’s recommended by @igrigorik I really don’t want to change that.

(lid) #13

I think the config has the ciphers needed by CloudFront, as mentioned in my previous post.

If your fix made it work for @aahank then the issue of this post is not related to ssl issues obviously, or
potentially the version he used at the time did not have the same nginx ssl config as today?

@aahank you should probably check with this fix applied and see if cloudfront still give you any problem

(Sam Saffron) #14

I am very reticent to muck with our ciphers in any way that is not recommended by

I think it is correct to ship our defaults inline with that.

@codinghorror I think we can either close this or recategorize as support.

(Jeff Atwood) #15