2
\$\begingroup\$

I was looking at this question from almost 2 years ago, and wanted to click the first link, which is to this url: https://meta.codegolf.stackexchange.com/a/2073/25180.

That took me to a site that Chrome (59.0.3071.115) flagged as "not secure" on the grounds of

NET::ERR_CERT_COMMON_NAME_INVALID

The https: at the beginning of the url is crossed out as well. The same thing happens for the next link (https://meta.codegolf.stackexchange.com/q/2447/25180).

I've looked at a few meta links which don't have this issue and seen that rather than start

https://meta.codegolf.stackexchange....

They start

https://codegolf.meta.stackexchange....

Did some change take place in the meta url a few years ago leaving links like this abandoned? Does SE's SSL license not cover the meta.codegolf domain (and perhaps previously did)? Is this actually any sort of security fault (seems like leaving https while still logged in might be, but I don't know enough about it)?

I'm not currently in a situation where I can ignore the warning and go the site anyway (I'll check it out when I can), so I don't know what the behavior is after following the link, but I feel like this in and of itself is worth bringing up anyway.

\$\endgroup\$
3
  • 2
    \$\begingroup\$ Take out the s in https and it fixes the problem temporarily. We switched from meta.codegolf to codegolf.meta at some point, and I believe we also switched from http to https, so something's wonky in there. You can also swap the meta and the codegolf. \$\endgroup\$
    – Stephen
    Commented Jul 19, 2017 at 13:33
  • \$\begingroup\$ Yep, as Step Hen said, all of Stack Exchange switched to https a couple months ago. As a side effect, all meta sites became name.meta instead of meta.name. \$\endgroup\$ Commented Jul 19, 2017 at 14:11
  • 1
    \$\begingroup\$ Here's the mother meta post -- meta.stackexchange.com/questions/292058/… \$\endgroup\$ Commented Jul 19, 2017 at 14:12

1 Answer 1

3
\$\begingroup\$

https://meta.codegolf.stackexchange.com has never worked. Somebody made that edit manually without checking whether it worked. I’ve fixed it.

\$\endgroup\$
3
  • 2
    \$\begingroup\$ For some value of "worked". Actually it always worked fine: the certificate wasn't valid for the name, but at a level of human rather than automatic checking it was good. \$\endgroup\$ Commented Jul 22, 2017 at 5:52
  • \$\begingroup\$ @PeterTaylor: Well, for values of "always" excluding the time (from about two years to a year ago) when CloudFlare broke it. \$\endgroup\$ Commented Aug 31, 2017 at 9:34
  • \$\begingroup\$ HTTPS without a valid matching certificate never counts as “working”. It’s worse than broken—it conditions users to click through certificate mismatch warnings on other HTTPS websites even when they may be under attack. \$\endgroup\$ Commented Aug 31, 2017 at 17:28

You must log in to answer this question.

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