2

Just a note that when I tried to go to "https://www.superuser.com" (as many of us are want to type in, including the www) I get a certificate warning. I don't get the same error when I go to "https://superuser.com".

Up to you as to whether that's a problem or not, just thought you should know.

www.superuser.com uses an invalid security certificate. The certificate is only valid for the following names: *.stackexchange.com, stackexchange.com, meta.stackexchange.com, stackoverflow.com, *.stackoverflow.com, stackauth.com, sstatic.net, *.sstatic.net, serverfault.com, meta.serverfault.com, superuser.com, meta.superuser.com, stackapps.com, openid.stackauth.com, *.meta.stackexchange.com (Error code: ssl_error_bad_cert_domain)

9
  • www.superuser.com simply redirects to superuser.com. It's not used anywhere, and never has been AFAIK. The only way to get there is to enter the wrong URL directly.
    – Daniel Beck Mod
    Commented May 12, 2014 at 20:26
  • Www is bad!
    – allquixotic
    Commented May 12, 2014 at 20:33
  • How did you get to www.superuser.com instead of superuser.com?
    – random Mod
    Commented May 12, 2014 at 20:34
  • Note: I'm running the HTTPSEverywhere add-on in Firefox, which seems to route me to https + ://www.superuser.com if I type in www.superuser.com - which does not immediately redirect me to the non www site. What can I say, I'm old and used to typing in the www ;?)
    – cpuguru
    Commented May 12, 2014 at 20:35
  • 1
    It can't redirect you before the SSL connection has been established. I'm calling this one a user error. Issues caused by HTTPS Everywhere are numerous and well known (e.g. BBC).
    – Daniel Beck Mod
    Commented May 12, 2014 at 20:44
  • 2
    @DanielBeck I wouldn't call it a user error; it's extremely non-user-friendly for https://www.somesite.com to throw a cert error. A cert for *.superuser.com should exist. Yes, it's added expense, but it was SE's fault for choosing not to make everything a subdomain of *.stackexchange as it is (it's less characters to type superuser.com, sure, but also more expensive to support multiple domains). Both the no-www and yes-www crowds strongly recommend that all sites support both www and naked domains; SSL is just a special case of that.
    – allquixotic
    Commented May 12, 2014 at 20:47
  • And don't blame it on HTTPS Everywhere, either; security is important; man in the middle attacks are becoming more common; and there is very strong justification for users to desire security (to prevent session hijacking, for instance). I wouldn't be surprised if browsers such as Chrome and Firefox start implementing functionality like HTTPS Everywhere into the core browser and enabled by default within the next few years.
    – allquixotic
    Commented May 12, 2014 at 20:50
  • 4
    Unless I missed something, HTTPS isn't officially deployed yet. The reason you land on a HTTPS site is that the rules in HTTPSEverywhere are broken.
    – Oliver Salzburg
    Commented May 12, 2014 at 21:23
  • In a browser address bar, Ctrl+Return adds a .com to the end of whatever you've typed, and www. to the beginning, @random.
    – TRiG
    Commented May 13, 2014 at 14:08

1 Answer 1

Reset to default
5

You bring up a valid point. Based on the description of your problem, I would consider this to be a bug that should be resolved by the SE team by adding a valid SSL cert, either specifically for www.superuser.com, or for *.superuser.com.

Account security is a very important subject, and SE has been investing lots of time and resources into getting SSL working across all their services. This is a commendable effort, but SSL is still a work in progress for them, and they have not had the time or resources to get certificates issued for every domain and subdomain. www.superuser.com is a valid way to access Super User, even if it's not the preferred way.

Both no-www and yes-www -- two disagreeing camps on whether or not to use www in URLs -- agree on the point that every website should be accessible via both the "naked domain" (e.g. http(s)://superuser.com) and via its www. equivalent (e.g. http(s)://www.superuser.com).

As of now, we have the following situation:

http://superuser.com -- Works fine.

http://www.superuser.com -- Works fine, redirects to http://superuser.com, compliant with no-www standards.

https://superuser.com -- Works fine for protecting your session cookie. Some site resources are loaded over unencrypted channels, but this is only a risk for content injection; the browser security model still makes it difficult to extract the session cookie cross-domain without obtaining local user trust, which is generally not practical. So you get a security upgrade, and otherwise the site is fine.

https://www.superuser.com -- Broken! There is no standards justification I can find to support leaving this broken, and it's liable to scare away or discourage at least a couple users.

2
  • 3
    https isn't officially deployed, and till it's done, I wouldn't consider it as a bug
    – Sathyajith Bhat Mod
    Commented May 13, 2014 at 4:41
  • 1
    @Sathya Adding a cert for www.superuser.com should be considered part of the deployment process for completing the rollout of HTTPS, then. SE does things gradually and iteratively rather than just rolling out the whole thing in one finished lump; having this cert added would bring them closer to being "done". By the same token, they couldn't sanely call the HTTPS rollout "done" in any way until all their domains that are accessible over HTTP are also accessible over HTTPS.
    – allquixotic
    Commented May 13, 2014 at 13:15

You must log in to answer this question.

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