brian wrote:

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.

jeluf wrote:

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. :-)