Last modified: 2014-11-17 10:35:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T22643, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20643 - Serve SSL/HTTPS sites out of same domain names as HTTP access: https://en.wikipedia.org/
Serve SSL/HTTPS sites out of same domain names as HTTP access: https://en.wik...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
SSL related (Other open bugs)
unspecified
All All
: Normal normal with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
https://en.wikipedia.org/
: ops
Depends on: 16822 29969 31333
Blocks: ssl 225 20454 21948 23559 27622 29053 29896
  Show dependency treegraph
 
Reported: 2009-09-14 16:30 UTC by Brion Vibber
Modified: 2014-11-17 10:35 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2009-09-14 16:30:32 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.
Comment 1 Brian Jason Drake 2010-12-29 16:36:01 UTC
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
Comment 2 Mark A. Hershberger 2011-03-06 21:30:12 UTC
Giving half of Fred's old bugs to Jeluf since I trust him to handle them or give them away if he can't.
Comment 3 JeLuF 2011-03-07 06:49:27 UTC
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.
Comment 4 Jimmy Xu 2011-03-07 08:56:37 UTC
(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).
Comment 5 Sam Reed (reedy) 2011-07-06 20:10:23 UTC
Removing "shell" keyword for things that aren't directly doable by shell users etc
Comment 6 Brion Vibber 2011-07-06 20:13:24 UTC
Restoring "shell" keyword for things that only a subset of shell users can possibly do.
Comment 7 Sam Reed (reedy) 2011-07-06 20:31:27 UTC
Adding ops keyword
Comment 8 Sam Reed (reedy) 2011-07-06 20:31:58 UTC
Removing shell keyword if exists
Comment 9 Brion Vibber 2011-10-03 20:41:32 UTC
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).
Comment 10 Tim Starling 2013-08-16 06:25:44 UTC
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.
Comment 11 Andre Klapper 2013-08-16 09:26:01 UTC
What exactly is blocking marking this ticket fixed? 
I don't see any dependency bugs left.
Comment 12 MZMcBride 2013-08-16 14:47:54 UTC
This is fixed. Thanks to everyone in the Wikimedia operations team for working to make this happen. :-)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links