This change to URL structure is correct. If you look at the URL in your browser now you will see the updated structure with the expected
https as well as
And if you type into your address bar
meta.gis.stackexchange.com it will automatically update to
This is correct, was planned, and was listed as a change in the same Meta SE Q&A that announced the change to HTTPS.
- (Child metas) Move from meta.*.stackexchange.com to *.meta.stackexchange.com.
As yet I am unsure the reason for this change, and have added a comment on the Meta SE Q&A asking about the purpose.
The reason for this change is because you can have wildcards to the left of an address for a site certificate e.g.
*.meta.stackexchange.com but not a wildcard in the middle of an address like
meta.*.stackexchange.com, so it makes it easier to apply certificates to meta sites if they are all a subdomain of Meta.
Ok so the top level domains are easy, a SAN cert which allows many
domains on a single cert – we can sanely combine up to 100 here. So
what about all of our
*.stackexchange.com domains? A wildcart cert,
excellent we’re knocking these out like crazy. What about
meta.*.stackexchange.com? Damn. Can’t do that. You can’t have a
wildcard of that form - at least not one supported by most major
browsers, which means effectively it’s not an option. Let’s see where
these restrictions originate.
Section 3.1 of RFC 2818 is very open/ambiguous on wildcard usage, it
Names may contain the wildcard character
* which is considered to match any single domain name component or component fragment. E.g.,
foo.a.com but not
foo.com but not
From Stackoverflow.com: the road to SSL
This may mean that some Q&As that link to the old GIS Meta site directly, such as this answer to Where has Meta of GIS Stack Exchange gone? may still refer to the old site, however an auto-direct is currently in place to send you to the correct site anyway.