4

I found a bug. It's either Google Canada's fault or Stack Exchange's fault, or a combination. I'm not sure which.

Steps to reproduce

  1. Do a Google Canada search for: [ android stack exchange questions tagged faq-proposed ].

  2. Click the first search result. The one with the title: "faq-proposed - Android Enthusiasts Meta - Stack Exchange".

Screenshot:

screenshot of search-results page

What happens

  1. Your browser loads https://meta.android.stackexchange.com/questions/tagged/faq-proposed

  2. The security certificate covers *.meta.stackexchange.com but not meta.android.stackexchange.com. So your browser shows an error message. The key part of the message is this:

meta.android.stackexchange.com uses an invalid security certificate.

The certificate is only valid for the following names: *.stackexchange.com, stackoverflow.com, *.stackoverflow.com, stackauth.com, sstatic.net, *.sstatic.net, serverfault.com, *.serverfault.com, superuser.com, *.superuser.com, stackapps.com, openid.stackauth.com, stackexchange.com, *.meta.stackexchange.com, meta.stackexchange.com, mathoverflow.net, *.mathoverflow.net, askubuntu.com, *.askubuntu.com, stacksnippets.net, *.blogoverflow.com, blogoverflow.com, *.meta.stackoverflow.com, *.stackoverflow.email, stackoverflow.email

Error code: SSL_ERROR_BAD_CERT_DOMAIN

If you'd like, you may see a screenshot of the full error message.

What should have happened

Well, I was hoping not to see any error message. :)

Notes

I'm using Firefox Nightly 55.0a1 (2017-03-21) (32-bit) on Windows 10 Home. But this bug might be reproducible in all browsers.

Improve this question
8
  • 2
    That result puts me on the correct page. I mean the URL in the result even says "android.meta" and not "meta.android" so I'm not sure how you're ending up at the wrong place. Considering the "meta.android" path never worked over HTTPS with our certificate, Google shouldn't even have that URL cached anywhere.
    – animuson StaffMod
    Mar 26, 2017 at 3:53
  • Let me investigate.
    – unforgettableidSupportsMonica
    Mar 26, 2017 at 3:58
  • The bug happens on Google Canada (google.ca), but not google.com, I've edited my question to repoint the link to google.ca.
    – unforgettableidSupportsMonica
    Mar 26, 2017 at 4:01
  • 4
    This will fix itself in 6 to 8 weeks.
    – Michael Hampton
    Mar 26, 2017 at 8:05
  • Are you using HTTPS Everywhere or a similar extension?
    – TRiG
    Mar 27, 2017 at 9:33
  • @TRiGisTimothyRichardGreen: No, I don't use those kinds of extensions.
    – unforgettableidSupportsMonica
    Mar 27, 2017 at 9:46
  • @TRiGisTimothyRichardGreen: I accidentally found an example which affects Google.com as well. Do a Google.com search for [ purim torah disclaimer ]. You'll see these results. The first result attempts to send you to meta.judaism.stackexchange.com.
    – unforgettableidSupportsMonica
    Mar 31, 2017 at 15:42
  • I'm seeing the same, @unforgettableid. Odd. HTTPS never worked for that domain, so it's very strange to me that Google indexed it.
    – TRiG
    Mar 31, 2017 at 15:45

1 Answer 1

Reset to default
5

The meta sites were recently renamed from meta.*.stackexchange.com to *.meta.stackexchange.com, exactly with the goal to avoid the continuous ssl problems. The ssl certs are valid only for the new names.

It still fails on the old sites.

The google.ca cache wasn't yet updated, its reason is probably inside the deepness of the google, but it will be probably soon.

The google uses many locations, many server farms, in many countries. Their databases is not always synchronized. Thus, you can see different content on google.ca, as from google.com.

In cross-continental problems, it is even possible, that you see a different google farm from different countries, but on the same IP (although it is not the case in a .ca - .com desync).

Currently, if you go to the old site names, you will get a redirect to the urls on the new names. But, the https request getting for this redirect will still use the old name, which is certified by the for him invalid cert.

This is why you get the error. Wait a little bit, until all byte finds his place in the google cache db. The SE probably can't do anything to accelerate it, but it isn't even needed.

Improve this answer
3
  • SSL never worked for the old meta sites, so Google shouldn't have them in its cache as HTTPS. I suspect that OP is using HTTPS Everywhere or a similar extension.
    – TRiG
    Mar 27, 2017 at 9:33
  • @TRiGisTimothyRichardGreen No, ssl still works also with invalid certificates, although it doesn't protect against mitm attacks. This is why the browsers drop these annoying warning windows against them. But it still protects against readonly eavesdropping. I personally used the whole SE with HTTPS, years long, although I had to override some https everywhere rule with it. (It is a firefox module to enforcing ssl everywhere.) Also google crawls and caches the sites with invalid ssl certificates (although it may be a disadvantage in its search result / hack detection preference algorithms).
    – peterh
    Mar 27, 2017 at 9:56
  • @TRiGisTimothyRichardGreen Before the current SSL fix, the SE still accepted HTTPS requests and served them correctly, only its certificate was invalid (-> you wasn't protected against mitm + had to pass annoying browser warnings). Furthermore, the internal links have leaded often to http:// urls, these had been overridden with some browser extension to enforce the https also in these cases. There were also problems that some banners came from external sites using http:// only, these caused MCB (mixed content block) errors, although an adfilter solved also this problem.
    – peterh
    Mar 27, 2017 at 10:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .