My site is down with a weird SSL notification

My website has been running for a long time now, and suddenly today, after checking the traffic analytics noticed that it’s been down for the whole day. tried getting into the website and I get this error:

"Your connection is not private

Attackers might be trying to steal your information from mydomain.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID"

I rebuilt the website, but nothing :frowning: and checked CloudFlare it seems fine. Contacted Godaddy there was no issue from their side at all.

I’m confused now any ideas?

Your site is presenting the wrong certificate, and has HSTS enabled. With the information available, there’s not a lot more detail we can give.

3 Likes

I didn’t enable it!

and more awkwardly, I didn’t touch any coding or server at all it just went down on its own!!! :o

HSTS can be enabled by the origin server, it doesn’t have to be enabled by Cloudflare. If you ticked “force https” in your Discourse site’s settings, then that’ll do it.

If your site is being proxied by Cloudflare, then it’s a problem at their end, and not something wrong with Discourse. Otherwise, check the certificate you’ve configured Discourse to use, and ensure that it matches the name you’re using to access the site.

3 Likes

Yep, I’ve done that on discourse side loooong ago, and it’s been fine since then.

there is no way to contact cloudflare :frowning: so is there a way I can “untick” the force https box from server side (as i can’t access my admin panel now). that way at least won’t be harmed that much :slight_smile:

thanks

Well, what you changed recently?

On Cloudflare DNS settings, is the cloud orange or gray? Try making it gray.

1 Like

Changed absolutely nothing! :flushed:

the cloud is orange, just changed it but nothing changed :o

When you change it from orange to gray, it changes the DNS entries, and it can take literally hours to propagate and update caches.

After you are sure the change is live, a rebuild should trigger a new cert (I’m assuming you are using our Let’s Encrypt setup).

1 Like

I followed these instructions from sam.

Yep, will be waiting.

So you bought a certificate? Maybe it expired? Did you check that?

Nop, I used free shared one :slight_smile: I don’t buy certificates :sunglasses:

Yes, but it won’t do any good, as any previous visitor to the site will have remembered that HTTPS is supposed to be enabled, and will fail to connect (as shown in the error you originally pasted).

Define “shared one”.

You’re really not helping us help you here. Please describe your exact setup, including the actual domain name at issue, where you got the certificate from and when, all the servers and proxies in your chain, and so on. Then we might have a hope of spotting what’s gone wrong. At the moment, it’s an endless game of psychic debugging, which is clearly not working.

3 Likes

If you shared your site name then people could look at your certificate and have more information to help you like whether DNS changes have propagated.

My best guess is that whatever certificate you got is expired. Can you say how or where you got it? The instructions you linked to don’t describe how to get a certificate.

The simplest solution would be to turn off cloudflare and rebuild your site with Let’s Encrypt.

You can turn off force_https like this:

cd /var/discourse
./launcher enter app
rails c
SiteSetting.force_https=false
exit
exit

But most browsers (like yours) will remember that the site is supposed to be https and will try very hard not to connect. Or, more elegantly:

4 Likes

My domain name is: stopbyte.com

I’ve tried this: SSL Server Test: stopbyte.com (Powered by Qualys SSL Labs)

any help now?
thanks

That’s a separate error message to “common name invalid”.

Even better, stopbyte.com isn’t emitting that error any more, it’s not saying the cert isn’t trusted, because it’s now presenting the Cloudflare special “Origin Certificate”, which is only trusted by Cloudflare. Put back the certificate you had before, and see what happens.

3 Likes

The TTL used by CloudFlare is only 300 seconds.

HSTS specifically takes longer because the browser has retained the instruction. For example on Chrome you can visit chrome://net-internals/#hsts and remove a domain, which will immediately bypass the old HSTS instruction.

Are you referring to the default shared SSL that CloudFlare implements? If not what’s the source?

In your app.yml did you enable support for Let’s Encrypt by uncommenting the entries for web.template.ssl and web.letsencrypt.ssl.template? They’re all you need for HTTPS at the server end. Once they’re working you can safely enable strict HTTPS at CloudFlare.

2 Likes

Phew Thanks a lot, this was really a terribly long day :weary:

That solved my problem, I think the issue been that there were tons of tutorials on this website on setting the SSL correctly and I guess I mixed them up.

It will be helpful having one unique simple tutorial (as you put it on your post) on doing this. and taking down the others.

Glad you got it fixed!

You still haven’t described what was wrong or how you fixed it, so it’s difficult to know which tutorial you found useful.

7 Likes

This topic was automatically closed after 2572 days. New replies are no longer allowed.