4

When Stack Exchange transitioned to HTTPS, meta.*.stackexchange.com subdomains were changed to *.meta.stackexchange.com subdomains. The old meta.* subdomains now redirect to the new *.meta subdomains. Trying to visit them over HTTPS causes a certificate error. The justification for the change was given in an answer to that post:

The old Meta URLs will never support HTTPS. The whole point of changing the path to *.meta.stackexchange.com was because wildcards cannot use meta.*.stackexchange.com and we couldn't apply a single certificate to all of the Meta domains. We are not interested in maintaining a bunch of certificates for all the domains just to support an outdated URL scheme that was replaced for the very reason we couldn't support it.

However, since then, Stack Exchange has switched to using Let's Encrypt to manage their certificates. Unlike traditional CAs, using Let's Encrypt makes it very simple for SE to manage their certificates. It seems unlikely that it would be hard for Stack Exchange to use Let's Encrypt to obtain certificates for all of their *.meta subdomains, since Let's Encrypt (exclusively) allows certificates to be acquired in an entirely automated process, significantly streamlining the certificate creation process. Adding TLS to these old URI would improve security and eliminate potential TLS errors encountered by users.

Note that I'm not asking for the actual URIs for per-site metas to be changed: I only want TLS to be added to the redirecting domains.

Improve this question
2
  • 1
    Let's Encrypt has its limits. Would they be able to create certificates for all those URLs easily without being rate limited? There's ~180 sites now.
    – Laurel
    Dec 8, 2021 at 1:27
  • @Laurel That documentation says you can have 100 names per certificate, and 50 certificates per eTLD+1 per week. So 2 certificates, each with ~100 subdomains, would suffice while still being far below the rate limits.
    – smitop
    Dec 8, 2021 at 1:35

2 Answers 2

Reset to default
6

HTTPS redirects (from https://meta.*.stackexchange.com to https://*.meta.stackexchange.com) now work. While fixing HTTPS wasn’t the goal (and we've said in the past that it wasn't worth fixing), a change in our internal architecture made it easy to fix, so we fixed it.

See my answer here for more details.

Improve this answer
15

I know you quoted my answer here, but Oded provided additional reasoning for why this is just not necessary:

  • We never linked to the old Meta schemas in any way using HTTPS protocols, so there shouldn't be any HTTPS links to those URLs where this certificate needs to exist. Any that existed using the old schema should have been using HTTP, which causes a redirect to the correct, secure version.
  • We rewrote all the links on our own sites to point to the correct new versions of those URLs.

We really prefer to cover all of our sites with a single certificate, and we are not interested in generating multiple certificates to cover portions of our sites even if it can be done automatically. Especially considering there is almost no benefit in doing so. Changes to the Let's Encrypt creation process do not change our position that we do not want to support this.

Improve this answer

You must log in to answer this question.

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