(In reply to comment #0)

From bug 34788 comment #8:

On a related note, if you go to .com addresses (like https://en.wikipedia.com/)
using HTTPS protocol, before you get forwarded to the .org address, you will
get an error message regarding the SSL key. That is because the .com addresses
use the SSL key that is for *.wikipedia.org

It'd be nice to know how common this is (usage stats, I guess). It's been quite some time since wikipedia.com was the primary domain. :-)

This includes https://wikipedia.com and https://wikipedia.net

Just a matter of $$$. Do we want to pay for this? As already mentioned, needs data/analytics to make an informed decision if it's worth it to get more wildcard certs.

• Bug 61228 has been marked as a duplicate of this bug. ***

From a technical point of view, I read a best practice could be not to add too much DNS domains in one certificate because it adds these some bits of certificate description to all clients. For *.com and *.net domains it could be worth issuing them in a distinct certificate, if any.

Personally I’m not convinced it is worth adding TLS on *.com or *.net since it is no more the canonical extension. And if stats are not soon available, I find it would be better to deactivate the TLS on these domains because certificate errors participate in lowering the global security by accustoming users to false positives (and this bug is currently really an error because signed and used domains mismatch, not just a self-signed certificate).

We could have those hosts go to a separate set of public IPs, and then refuse connections on port 443.

(In reply to Tim Starling from comment #6)

+1

This is one (particularly prominent) aspect of a the broader scope problem with having way too many mostly-useless domains over here: https://phabricator.wikimedia.org/T101048 . We have a ton of domains that get very little traffic and it's much more an issue with TLS as we don't want to encourage/allow linking insecure redirects, and we don't want to buy and manage 140+ TLS certs either.