Last modified: 2014-11-17 10:35:18 UTC
Longtime annoyance, really needs to be taken care of soon. :) We'll need: * HTTPS proxies on the same IPs as the various front-end HTTP proxies * Some reasonably sanely priced wildcard SSL certs Note bug 16822 covers this (or a simpler setup) just for upload.wikimedia.org, so we can "practice" there before fiddling with the main web servers.
I’m not sure if it’s worth filing an additional bug for this: once we do this, we can enable STS [0]. We should also get the HTTPS Everywhere [1] ruleset for Wikimedia sites and any similar data updated. [0] https://secure.wikimedia.org/wikipedia/en/wiki/Strict_Transport_Security [1] https://www.eff.org/https-everywhere
Giving half of Fred's old bugs to Jeluf since I trust him to handle them or give them away if he can't.
Is it possible to have multiple domains within a wildcard cert? wikipedia.org, wikimedia.org, wiktionary.org etc pp are all served from the same IP, so that we'd need a single cert for *.wikipedia.org and *.wikimedia.org and *.wiktionary.org etc.
(In reply to comment #3) > Is it possible to have multiple domains within a wildcard cert? SubjectAltName will do the job. But not all clients support it (AFAIS wget is one of them).
Removing "shell" keyword for things that aren't directly doable by shell users etc
Restoring "shell" keyword for things that only a subset of shell users can possibly do.
Adding ops keyword
Removing shell keyword if exists
This is now mostly live, but some sites don't work due to additional subdomains (bug 31335) and the mobile sites don't offer HTTPS at all on their front-end proxy (bug 31333).
This was fixed, and secure.wikimedia.org was made to redirect, the old scripts removed. So bug 31335 is more of an ongoing annoyance than a blocker.
What exactly is blocking marking this ticket fixed? I don't see any dependency bugs left.
This is fixed. Thanks to everyone in the Wikimedia operations team for working to make this happen. :-)