Last modified: 2014-09-02 07:45:04 UTC
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
(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
