Is this by design or a bug or is it just me?
@Jarland this is probably a side effect of the work that you’ve been doing.
Hmm, well that’s odd. It’s just a CNAME to the A record, proxied of course. I’m a little confused why it’s acting differently than it ever did before CF.
Let’s try killing the CF proxy for a bit and see if it’s the CF headers forcing the content security policy thing.
Had to sign a cert for it, was using flexible SSL
Now www isn’t covered by the SSL cert? That’s odd behavior for Discourse.
Maybe www hadn’t propagated yet, I’ll rebuild the app again later.
It’s working for me now
Let’s look on the bright side, it’s just a black screen, not blue screen of death.
The cert for www is?
Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for www.hostballs.com. The certificate is only valid for hostballs.com.
Error code: SSL_ERROR_BAD_CERT_DOMAIN
Yeah it’s still not signing the cert for www. This is something Discourse does on it’s own without any extra configuration, and it’s such a mess to deconstruct their methods this should take a while.
Probably for @Wolveix the redirect is cached, chrome does that.
Yeah I give up for the night, I think.
Seems this is the way Discourse handles itself now. I set up a test at mxroute.host and notice that www.mxroute.host is not part of the certificate either. So we’re just not a www site. Not interested in manually editing the configs but may do a redirect elsewhere later. I don’t want to have to manually adjust configs on every update of Discourse given how frequent they are.
Or I can just turn on CF proxy again and let it handle that, cheaper. But… then it does the content policy thing again.
Does www look good now to others?
Works for me now - yesterday it was an invalid cert.
Perfectly redirecting to non WWW.