SSL Certificates issue on Firefox/Chrome when using https


#1

Starting today I can’t access discuss.atom.io from Firefox/Chrome using https due to an issue with the certificate:

This Connection is Untrusted

You have asked Nightly to connect securely to discuss.atom.io, but we can't confirm that your connection is secure.

Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
What Should I Do?

If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.

discuss.atom.io uses an invalid security certificate. The certificate is only valid for the following names: *.discourse.org, discourse.org (Error code: ssl_error_bad_cert_domain)

Seems like the same issue occurs on blog.atom.io which serves a certificate valid only for www.github.com, *.github.com, *.github.io, *.githubusercontent.com


#2

I just ran into this issue too. It persisted until I completely exited and restarted Chrome. It seems like one of the servers in a load-balanced set is misconfigured?

cc @codinghorror @ProbablyCorey


#3

Still experiencing this issue, intermittently. Misconfigured load-balancer doesn’t seem unlikely :+1:


#4

Er… since when is https configured here at all? It hasn’t been since launch.


#5

I got redirected there automatically. Going to http://discuss.atom.io, redirected me to https://discuss.atom.io.
Although not directly relevant to you, the same happened when trying to reach http://blog.atom.io.


#6

Hmm, not sure where that redirect to https is coming from? I don’t see it, that is, when I come here, I get plain old http://


#7

Same here, I didn’t noticed I was in https until I get this message (damn browsers hiding protocols in address bar!!)


#8

Not sure, but as @leedohm suggested, it might be an incorrectly configured load balancer (or some such)? Only happened to me a few times yesterday. It was intermittent, and semi-sticky, so that does seem to support the load balancer hypothesis.

Just to make it clear, the redirect was forced server-side.


#9

Yep, I don’t see it anymore. And I only saw it the once yesterday. It persisted until I restarted Chrome. Even when I manually typed in http, the server would redirect to https.


#10

No it’s not happening server-side. It’s a side effect of visiting atom.io and being exposed to their HSTS configuration:

curl -v http://www.atom.io
< HTTP/1.1 301 Moved Permanently
< Location: https://www.atom.io/

curl -v https://www.atom.io
< HTTP/1.1 301 Moved Permanently
< Location: https://atom.io/

curl -v https://atom.io
< HTTP/1.1 200 OK
< Strict-Transport-Security: max-age=631152000; includeSubdomains

https://discuss.atom.io should not be configured - it happens to be listening but that’s not intended to be used.

So yeah… wait 20 years without visiting atom.io and try again? :smile:

Edit: I added http://atomio.discourse.org/ as a site alias - people can access via that URI and won’t get any warnings.


#11

Me too since this morning I can not access discuss.atom.io with chrome.
I added a certificate exception in firefox to access the forum

Type d’erreur : HSTS failure
Objet : *.discourse.org


#12

I just now opened another window and navigated to both atom.io and http://atom.io, waited for it to load and ensured that it was redirected to https://atom.io in both cases. From there, in the same window, I navigated to discuss.atom.io and did not encounter the same certificate issue reported above. I also reproduced your results with curl. So, something else was at work here.

If everyone is working now, then I guess it isn’t a big deal. And I see you added a workaround. Thanks @Supermathie.


#13

Check again - looks like they’ve modified the behaviour to not include subdomains:

curl -v https://atom.io
< HTTP/1.1 200 OK
< Strict-Transport-Security: max-age=631152000

Looks (emperically) like visiting https://atom.io and getting the new STS header clears the old behaviour - after visiting https://atom.io in my browser and forcing a refresh I can load http://discuss.atom.io without issue.


#14

Well, thanks to our mysterious benefactor! :laughing:


#15

We are actively working on fixing this (specifically @izuzak is actively working on this!)


#16

Sorry about this, everyone!

Looks (emperically) like visiting https://atom.io and getting the new STS header clears the old behaviour - after visiting https://atom.io in my browser and forcing a refresh I can load http://discuss.atom.io without issue.

Yeah, that’s the way to fix this issue yourself. Visit https://atom.io first, and that should refresh the config.


#17

Even better, we now have an SSL certificate deployed for https://discuss.atom.io/!


#18

This topic was automatically closed after 24 hours. New replies are no longer allowed.