Page MenuHomePhabricator

SSL cert needed for new fundraising events domain
Closed, ResolvedPublic

Description

Major Gifts is setting up a new event invitation and payment processing tool through Trilogy Interactive (see related tasks for more info: T101191, T104357).

Trilogy is helping to set up new pages for us at events.wikimedia.org and eventdonations.wikimedia.org, and want to know who they should contact about an SSL certificate. The donate.wikimedia.org has a wildcard SSL cert, so we could conceivably use that for the events site, but want to confirm this with Ops.

EDIT: We are fine with WMF purchashing a new cert as well. The domain is eventdonations.wikimedia.org

Event Timeline

CCogdill_WMF raised the priority of this task from to Medium.
CCogdill_WMF updated the task description. (Show Details)
CCogdill_WMF added a project: acl*sre-team.

@EWilfong_WMF is the relevant contact at Trilogy. Eric, if you have more specific questions, can you add them in a comment to this task?

Krenair added a subscriber: Krenair.
This comment was removed by Krenair.

donate.wikimedia.org has a wildcard SSL cert, so we could conceivably use that for the events site

But that's hosted by WMF... Shouldn't third-parties only get certs which match the domains they're actually hosting for Wikimedia?

I apologize as I don't know who the question above was directed towards, but I'll add some thoughts from our end. Since there is already a wildcard cert for the site, it would be redundant to purchase another one for the Major Gifts event tool. We will host the site, but the SSL cert is used to identify the site as legitimate and secure regardless of where the site is hosted. However, if Wikimedia prefers we purchase a new cert for this subdomain we are able to do that. We will need help from the ops team to approve the purchase of the cert; I can post more regarding this as we move forward with the purchase. Are there any specific requirements for the type of cert we should purchase?

Please let me know if you would like us to proceed with purchasing another cert or if we should work to use the existing cert.

We're definitely not handing a 3rd party the private key to a WMF wildcard cert. I don't think we'd authorize someone else to purchase certs in our name either. At best you're looking at us purchasing certs for these specific hostnames and then handing them over. All of that said, don't take that as my implicit approval of that as a path forward. We should really have some internal dialog about FR/donations and DNS/TLS issues before we create more situations to deal with.

@BBlack we're on a time crunch with this project. The first event is scheduled for 10/1, so we need this system to be live within the next 2 weeks. Who should we involve to move this dialogue forward?

Operations, probably myself and @RobH at least on the certificate-purchasing front. I imagine @mark and @faidon may have input or want to follow along as well. Ideally, we should've been involved in this much earlier. It's not a great feeling to get handed something questionable at the last minute and be told there's no time left to question it. Can we schedule a meeting about it (and other related issues of broader scope) this week?

I apologize about the timeline; we weren't able to request the cert until T104357 was resolved. Originally we thought we were ahead of schedule.

I'll set up a meeting this week. Can I get a sense of what the DNS/TLS issues are that concern you, so I know who I need to include from fundraising?

Brandon already covered this, but I'll add some clarification. Right now we have at least three third party sites hosting SSL, all of which do NOT use wildcards: shop.wikimedia.org, blog.wikimedia.org, and wikitech-static.wikimedia.org.

Each of these uses a certificate that is a non-wildcard. We've never (to my knowledge, and as the guy who orders 99% of the SSL certs, its likely correct) handed any third party a wildcard certificate. More to the point, we don't even allow wildcard certificates on most of our production systems. (We've narrowed the scope of wildcards to only exist on a specific sub-set of systems, which also only allow root/ops access.)

That being said, the domains listed: events.wikimedia.org and eventdonations.wikimedia.org are either two standard SSL certificates, or a single certificate with an additional SAN. A non-wildcard certificate costs 1/6th what a wildcard costs, so even buying two (or one with SAN) versus a wildcard is both cheaper and more secure. (Am I missing where using a wildcard is suggested for any other reason than 'it already exists'?)

I'll set up a meeting this week. Can I get a sense of what the DNS/TLS issues are that concern you, so I know who I need to include from fundraising?

In the broader context, I'm concerned about any further proliferation of this pattern of outsourcing critical sites that live within our production domainnames to 3rd parties. That should be a pretty exceptional circumstance with a really good justification (I don't think even the few we have now are well-justified). It raises all kinds of issues with certificates, with cross-domain trust/security issues in browsers (think cookies set on wikimedia.org ...), etc.

Specifically on the certificate front: any solution other than having WMF purchase the cert on our own and hand it to the vendor presents problems with HSTS and HPKP preloading of our domains in browsers. Even then, there are further operational concerns on two fronts. The first is that for all kinds of interrelated security reasons we don't want to purchase certs with long lifetimes (we're keeping it down to 1 year at present, but I could even see us trying to go shorter in the future), and thus each 3rd party vendor set up this way also involves a once-per-year additional cost outlay and coordination with them on rotating to a new private key and new cert. There's also concerns with operational practice mismatches with their TLS implementation on things like browser compatibility and basic minimum security levels.

All of those things aside, in the broader context of both this ticket and the other issues touched on recently with email.donate.wikimedia.org + Silverpop, and perhaps other such issues I might not even be aware of yet: It concerns me that potentially private information about donors is passing through third parties at all. How well do we trust these third parties in a legal sense to manage the privacy of that data? What about in an operational security sense? Those concerns face anyone using a 3rd party service for things like this, but they become even larger considerations when one factors in that we're an abnormal client. Most of these organizations are built to serve the needs of commercial entities who explicitly want to exploit and share private customer data for marketing purposes, whereas we're a non-profit that values our users' privacy to a higher degree than the industry norm for these 3rd parties' other customers.

Having now read some of the traffic in the other linked tickets: can we at least be sure we get HTTPS working on both new domains as well? We're trying to eliminate all endpoints within wikimedia.org that aren't HTTPS-capable (and then some, ideally). Adding events.wikimedia.org as HTTP-only would be a step backwards on that front.

We thought using the wildcard cert for donate.wikimedia.org already has was the easiest thing, but I can see your concerns so I've edited the task description to clarify that we are also fine with WMF purchasing a cert that we can use.

The only domain for which we need a cert right now is eventdonations.wikimedia.org.

We decided that events.wikimedia.org would be http for now because we are unable to use https on this system without breaking the page for users on XP / IE and other combos of old operating systems and browsers. The reason we can't have events.wikimedia.org over https is Trilogy's system is multi-tenancy. They can use Server Name Indication(SNI), which would allow multiple domain certs to exist at the same IP, however older browsers may not support SNI. See https://en.wikipedia.org/wiki/Server_Name_Indication#Implementation.

This tool will be used for a small number of major donors only, and that cohort is more likely to be using older operating systems.

My understanding from T102827 is that there are other subdomains running on http currently. Is it possible for us to get the cert for eventdonations.wikimedia.org and run this system for now so that we can get invitations out for this event as soon as we need to? We can continue conversations about what to do with events.wikimedia.org going forward.

It concerns me that potentially private information about donors is passing through third parties at all. How well do we trust these third parties in a legal sense to manage the privacy of that data? What about in an operational security sense?

Legal has reviewed and approved contracts with all 3rd party contractors who manage data, and their approval process isn't easy! We wouldn't be able to process payments if we didn't involve third parties so I'm not sure this argument makes sense for an organization with a fundraising model. The eventdonations.wikimedia.org site, the only one which has any forms to collect donor data, will be PCI compliant and @csteipp spoke with one of our Trilogy contacts to determine the security of their systems on 7/17. What other steps should we take to determine operational security?

We thought using the wildcard cert for donate.wikimedia.org already has was the easiest thing, but I can see your concerns so I've edited the task description to clarify that we are also fine with WMF purchasing a cert that we can use.

All other things I've said aside, the primary reason we can't share the wildcard key is it gives the third party access to impersonate any and all of our other sites, and makes all of our operational security for our private key dependent on their operational security to boot. I think the reason we've gotten a little hung up on that is that it's kind of crazy that anyone would even suggest that option, and speaks volumes as to their point of view on security issues...

The only domain for which we need a cert right now is eventdonations.wikimedia.org.

We decided that events.wikimedia.org would be http for now because we are unable to use https on this system without breaking the page for users on XP / IE and other combos of old operating systems and browsers. The reason we can't have events.wikimedia.org over https is Trilogy's system is multi-tenancy. They can use Server Name Indication(SNI), which would allow multiple domain certs to exist at the same IP, however older browsers may not support SNI. See https://en.wikipedia.org/wiki/Server_Name_Indication#Implementation.

This tool will be used for a small number of major donors only, and that cohort is more likely to be using older operating systems.

This doesn't make basic sense to me, for a number of reasons:

  1. It's generally impossible on the current internet to support HTTPS at all in a way that's both actually-secure and supports IE6/XP, due to the Poodle attack last year. Regardless of SNI, the HTTPS site for eventdonations.wikimedia.org will be broken for the same users you're trying to save on events.wikimedia.org...
  2. Our own production sites are in a similar boat (as is the rest of the world). IE6/XP is already dead to wikipedia and cannot access us at all. It seems unlikely that donors need lowered access requirements as compared to the primary wiki sites themselves - they couldn't even use/read what what they're donating to support.
  3. The browsers you're talking about saving access to have ridiculously severe security flaws. The donors might thank you for making it a little more obvious that if they're using these systems for anything financial or personal in nature at all, they're exposing themselves to some pretty severe risks...

We've been way way way down the deep rabbit hole of all of these complex implementation, security, and compatibility tradeoffs for our primary production sites already, and we have a standardized setup that works well and gives the best compatibility we can without compromising security. But once you step out to a third party, all bets are off and everything has to be evaluated from scratch again about how they're configured. Generally speaking, the average site out there is configured pretty poorly...

My understanding from T102827 is that there are other subdomains running on http currently.

There are a few, but not many, and we've been actively trying to eliminate them for some time now. It's a mess, and adding more just extends that timeline and mess.

@BBlack, we should definitely NOT give them our wildcard key. We will need to work out a safe way to get them subdomain certificates-- I think we should probably generate the key and get the certs, then send them the private key, instead of having to trust them to safely generate a key that we're going to put our name on.

Caitlin, I didn't realize the plan was for events.wikimedia.org to be http only. As Brandon has said, if we're afraid donors aren't using a modern browser, then they won't be able to connect to Wikipedia either. It's some extra work for them, but I don't think there's a valid technical reason for them to not set that up for us.

Thanks, @BBlack and @RobH for the insight into current operating procedure for third-party sites hosted over HTTPS under the wikimedia.org domain. We were not given direction regarding a SOP for this process, so that helps immensely. I understand your concerns re: the wildcard certificate and agree that you should generate the certs on your end.

Re: SNI, one clarification is that this will exclude all IE users on Windows XP. We are happy to set up events.wikimedia.org on HTTPS and recommended that we do so, but we wanted to provide the limitations of SNI upfront to the fundraising team. Ultimately this is a decision for Wikimedia to make internally, but I wanted to clarify that we are able to accommodate either decision.

As an aside, I must stress that we take the security of our system very seriously and we're happy to discuss any specific concerns you have. We have hosted large clients on our payment processing platform for 12 years and I’m confident that we can assuage any concerns regarding security of our system and the privacy of the data passing through it.

The concern for us lies in what @EWilfong_WMF just said — SNI
incompatibility on XP applies to all versions of IE, not just IE 6. So for
XP users with IE 7+, they would be able to see eventdonations.wikimedia.org,
but not events.wikimedia.org if it were https.

We don't have a way of knowing what OS our donors use, so we can't give an
estimate of how many use XP, but we operate under the reasonable assumption
that due to the age demographic of most of our major donors, they are
unlikely to have up to date operating systems. This is a real concern when
dealing with these donors.

I can see that we may not be able to use events.wikimedia.org on http for
the long term, so we will have to see what our best alternatives are. In
the meantime, we have only a couple weeks to get out the first round of
invitations through this system, and it's already taken months to get as
far as we are now! Is it possible for us to move forward with the one cert
for now, and then have a meeting to discuss solutions after?

@BBlack if you'd still like to meet to have a broader conversation about
fundraising and third parties, let me know. That conversation is much
bigger than me so I will need to get Lisa and Megan involved.

For reference, IE7 and 8 on WinXP account for at most 0.6% of total traffic on a global weekly average basis, and the bulk of that tends to look like it comes from office hours in the Global South. That's a stat we're hoping to help reduce through some campaigning aimed at getting users to upgrade sometime soon, but regardless we can't drop support for it until that number gets significantly lower I don't think.

The other remaining significant non-SNI case for users is Android 2.x: it should be roughly 1% of current traffic based on past related estimates, but I don't have a firm current number for it on-hand ( https://stats.wikimedia.org 's last report seems to roughly align with that estimate, though). We still support both of these on the primary sites and probably will for quite a while yet, but we're not explicitly supporting them on our "misc" services cluster for sites like Phabricator, git, etc (they have at different times either been broken for the misc services cluster or not, depending on other configuration changes made for unrelated reasons).

We can delay adding HTTPS for the events site, but we'd still like to commit to eventually correcting that (and the other cases that are outstanding, all of which are blocking progress for gaining full TLS security for other critical sites within wikimedia.org). If non-SNI compatibility is a requirement, that can be addressed by dedicating an IP address to it (here, or at a 3rd party) so that it can be the non-SNI default domainname for an HTTPS server instance.

And yes, I think we should still have a broader conversation about how we handle 3rd-party hosting in the wake of HTTPS: the bar for using 3rd parties to host sites in our primary domains at all should probably be higher than it has been in the past to avoid various related issues. There are also alternative options that create less mess, such as using a separate new 2nd-level domain we own, or simply using service hostnames within the 3rd party's domains that they control, either of which avoids interfering with all of these issues for wikimedia.org itself. We don't yet have a clear policy on this going forward, but FR is probably the most complicated case, so resolving how to handle it here would be a good step forward.

We can delay adding HTTPS for the events site, but we'd still like to commit to eventually correcting that (and the other cases that are outstanding, all of which are blocking progress for gaining full TLS security for other critical sites within wikimedia.org). If non-SNI compatibility is a requirement, that can be addressed by dedicating an IP address to it (here, or at a 3rd party) so that it can be the non-SNI default domainname for an HTTPS server instance.

Thanks for being flexible with us, and for providing some ideas for solutions to the long-term https issue here! @BBlack I'm sending you a calendar invite which is my reminder and commitment to you that I will let you know what our plans are to address this going forward. I've put this on 10/7, which is a week after the big event we're working towards ends. Let me know if that works with your timeframe.

Is there anything you need from us to get generate the eventdonations.wikimedia.org cert?

For this broader 3rd party conversation, Megan, Lisa, and I have a meeting with Terry next Wednesday. We'll broach the subject with him and then I will schedule something with you, Mark, Rob, and Faidon after that. Does that sound good?

My take (pardon me for repeating what others have said):

  • I don't think we should be adding any new non-HTTPS sites at this point. We've taken a very deliberate policy decision as an organization to commit to HTTPS-only so something like this would be technically against this policy. We have already implemented this for our most important and popular assets/websites, so it's hard for me to see why it would be more contentious to do it for smaller sites such as this one. If there is a extra price to be paid for this, we should factor it in our decision and pay it.
  • It's already impossible from a technical perspective to set up a new non-HTTPS sites in every domain of ours with the exception of wikimedia.org (e.g. if the request was for events.wikipedia.org, it would be completely impossible from a technical implementation perspective). The only reason this is still technically possible for wikimedia.org is that we have a legacy backlog and we need to slowly fix that. Any new additions at this point are just increasing our backlog and contributing to technical debt.
  • As others said, I don't think it makes sense to worry about OS/browsers combos not being able to access this site over HTTPS when they are already unable to browse our main websites (Wikipedia etc.). This includes IE6/XP. That said, we do not require SNI to access our main site (but we do require it for various other smaller sites of ours, including e.g. Phabricator or the Wikipedia Store). So, yes, certain combinations like IE8/XP would work with the main site but not with an SNI website.
  • Whether we should support such ancient OS/browser combinations aside, it's still unclear to me why is this a strict requirement: can't Trilogy work around this by getting an additional IP just for us?

I appreciate the concerns regarding setting up a new page on http. It has become clear to us that we cannot allow this page to be http for the long-term. However, for this specific donor base, losing support of XP + any version of IE is not trivial. XP is still a common OS in large corporations as well as for older generations, and our major donors are likely to fit into these categories.

I made a commitment to @BBlack yesterday that I will present our plan for how to migrate the page from http to https on 10/7/15 — there's a calendar invite which we have both accepted so this won't slip by. We can't say right now if that solution will be https through SNI or a new IP (this is not a simple solution for Trilogy with their current system), but we have committed to finding a solution either way. @CaitVirtue and I agree that we will make this change this fiscal year; if Ops has a stricter deadline, let us know.

We need use of this tool by 8/10 so we do not have time to implement a complicated solution for https right now. All we are asking is the ability to use this tool with one of the two domains on http for two months and get our major Fall event out of the way. I'd like to apologize that it may seem I'm dropping this on you last minute; I initially brought this project to Ops on 6/29 which was the day the payments contract was finalized, and I incorrectly assumed these requests were simple. This has been an important learning experience for me and I will certainly start these discussions with a few months' buffer whenever possible in the future.

Is the above compromise, in which we commit to change this page to https this FY and present a plan to do so on 10/7, amenable?

CCogdill_WMF raised the priority of this task from Medium to High.Jul 29 2015, 8:31 PM
CCogdill_WMF added a subscriber: astillwell.

XP is still a common OS in large corporations as well as for older generations

Ignoring the rest of the current discussion and just going little deeper on this one point: Microsoft ended all support for Windows XP a little over a year ago ( https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support ). There are known security flaws throughout XP and Microsoft has no intention of ever fixing them; it's effectively insecure abandonware at this point.

Ignoring the rest of the current discussion and just going little deeper on this one point: Microsoft ended all support for Windows XP a little over a year ago ( https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support ). There are known security flaws throughout XP and Microsoft has no intention of ever fixing them; it's effectively insecure abandonware at this point.

When it comes to contacting donors, the question is not whether they are using a supported or secure OS or not, it is simply if we can support whatever system they are using. We cannot be tasked with asking our donors to upgrade their systems.

Per http://www.netmarketshare.com/, this quarter XP has the second highest market share of all OS versions. We can't assume this won't impact our donors, especially with the specific group these events are targeting:

Screen Shot 2015-07-29 at 1.44.28 PM (2).png (465×1 px, 78 KB)

Per http://www.netmarketshare.com/, this quarter XP has the second highest market share of all OS versions. We can't assume this won't impact our donors, especially with the specific group these events are targeting:

Screen Shot 2015-07-29 at 1.44.28 PM (2).png (465×1 px, 78 KB)

I'm not wading into the upgrade thing, but just talking about stats. Keeping in mind we already killed IE6 access some time ago, IE7/8-on-XP (the ones with horrible TLS security and no SNI support) at our TLS terminations still only account for at most 0.6% of traffic, which is starkly different than those OS marketshare graphs for XP in general. I'm not really sure of what the discrepancy is there, but it's possible a lot of it is that most remaining WinXP users have installed an alternate browser, or simply don't use Wikipedia significantly to begin with and thus are underrepresented in the stats I'm looking at.

Keeping in mind we already killed IE6 access some time ago, IE7/8-on-XP (the ones with horrible TLS security and no SNI support) at our TLS terminations still only account for at most 0.6% of traffic, which is starkly different than those OS marketshare graphs for XP in general.

Our major donors are not our normal users, and if I'm doing my math right, 0.6% of traffic still comes out to ~2.7 million users. When we're talking about contacting a maximum of a few thousand people who are in a very specific, generally older demographic, we aren't willing to take the risk that they do not make up part of that 2.7m.

Our major donors are not our normal users, and if I'm doing my math right, 0.6% of traffic still comes out to ~2.7 million users.

Yes, something like that, which is why we still support it. It will be a long road before we can get that number down to an acceptably low level, probably. But my point there is, I think the OS Marketshare stats for overall XP deployment paint a much uglier picture than the stats we see for IE7/8-on-XP in terms of cipher negotiation limitations.

I see your point about the unreliability of the OS Marketshare metrics when it comes to overall Wikipedia usage. I just want to illustrate the significance of XP in this particular task.

If the compromise I suggested above (to restate: we commit to change benefactorevents.wikimedia.org to https this FY and present a plan to do so on 10/7) doesn't work, I would like to offer one alternate suggestion. Can we use the wikimediafoundation.org domain instead?

wikimediafoundation.org is HTTPS-only already. All of our existing primary domains are, except for wikimedia.org (which is only lagging because of unresolved exceptions like these).

On this basic issue of HTTPS for benefactorevents, the only real technical issue seems to be using a provider than can give us a unique IP for non-SNI HTTPS, right? That doesn't seem difficult. Can Trilogy do this for an extra cost?

@BBlack we're looking into the possibility, but if it's possible, it would
be a solution we could implement in 2 weeks. That is one of the options we
would talk about on 10/7, after the event is over.

Sorry, it would *not be a solution we could implement in 2 weeks...

So does that mean the vendor can't give us a unique IP to handle the SNI problem at this time? If they supported it at all, I imagine it would be pretty straightforward.

As Eric mentioned earlier in this task, Trilogy runs on a multi-tenant
system, so their system is not currently set up to add new IPs. They are
looking into whether or not they can do that for us, but it would not be
simple for them to set up an entirely new system for us.

Hi all,

I appreciate all the concerns you've shared with us and I can see that in the very near future we need to do this differently. Caitlin Cogdill has proposed a plan to fix this issue after the fall event. I've quoted that info out below.

In the meantime, we need to set this system up for the coming event ASAP. Please let us know the next steps to move forward on this.

Caitlin V.

From CC: "I made a commitment to @BBlack yesterday that I will present our plan for how to migrate the page from http to https on 10/7/15 — there's a calendar invite which we have both accepted so this won't slip by. We can't say right now if that solution will be https through SNI or a new IP (this is not a simple solution for Trilogy with their current system), but we have committed to finding a solution either way. @CaitVirtue and I agree that we will make this change this fiscal year; if Ops has a stricter deadline, let us know.

We need use of this tool by 8/10 so we do not have time to implement a complicated solution for https right now. All we are asking is the ability to use this tool with one of the two domains on http for two months and get our major Fall event out of the way. I'd like to apologize that it may seem I'm dropping this on you last minute; I initially brought this project to Ops on 6/29 which was the day the payments contract was finalized, and I incorrectly assumed these requests were simple. This has been an important learning experience for me and I will certainly start these discussions with a few months' buffer whenever possible in the future.

Is the above compromise, in which we commit to change this page to https this FY and present a plan to do so on 10/7, amenable?"

I'm generally agreeable to the plan, but I'm still a bit worried about the timeline here. We don't have firm deadlines, but presenting a plan on Oct 7 doesn't mean being ready to make the switch on Oct 7. Right now we're in the process of cleaning up these issues in wikimedia.org so that we can bring that last domainname into compliance with the upgraded security of our other major domainnames. The only truly-difficult case still blocking us on that effort today is the email.donate case (which is similar in nature: FR-related and 3rd-party hosted). The timeline on that one is still an unknown, but I was certainly hoping to resolve it much earlier than October somehow. Between email.donate and these new names, they will both block turning on HSTS preloading and/or HPKP for all of *.wikimedia.org until whenever after Oct 7 we finally get them resolved on a technical level.

Getting back onto the technical tasks at hand: the DNS part is merged now, and AIUI we (ops) need to purchase a cert from globalsign (RSA, no wildcard/SAN, single hostname for "eventdonations.wikimedia.org", 1yr validity) and hand it off.

@EWilfong_WMF - do you have a way for us to hand off the private key to you securely? (e.g. a PGP public key)

Sure. Here's my public PGP key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: Encryption Desktop 10.3.2 (Build 15917) - not licensed for commercial use: www.pgp.com

mQGiBEJK+9wRBADOc1nXGtBXScwCCW0wrlz/cGxIq960N3Ig1DXTC2p9yZMKPJ+C
ANl71mr+vZJu9ldT3g8Oev/hRSTwR90xMKCyPOy7oxFlm6WXx5M+fBc0IVaEiV8T
lXOUsOAELTolxfoAaQoqpKq3rMPtsem5Yuc1a7tO/YAjsWbqGTdxh+dsdwCg/8le
NchIags3fHShb7unf9E4dW0D/3bfAdz432AskVX0gRkNhUKqF50S1+2DmvvpmcjO
ytE47ua2HWkZ+RkJ+oEscgXu1rpE1jh17yUc/luqUer9jcs+Ff41UQ2MKs45zq1c
voXKs1fybsonWV8jbIJR784kRXXU7/ILJGcSMobr+5w0fTex9WnBlhx1Gamn8EeX
VsgBBAC61+I3eFCjIL1GrfXZa7MJi6cQp89KbDujLQEsLfvSgU7Gby/wkP0w3aZ4
8vzqnr+G6r1B0ssZoCAjDgk+ekNcsZUxWjvPYxjgzb9K3r2COJaycPRKtR0WtSVL
zTmhNdiF8vchPL5mxBmnKSu+AQndesPCOb89pB4hl96omE5YvrQsRXJpYyBXaWxm
b25nIDxld2lsZm9uZ0BtYXlmaWVsZHN0cmF0ZWd5LmNvbT6JAHwEEBECADwFAk1Z
mkUHCwkIBwMCCgIZABkYbGRhcDovL2tleXNlcnZlci5wZ3AuY29tBRsDAAAABR4B
AAAABBUICQoACgkQvbeFpHWitKsGAACfeJG0Wm2/UP0heQV74yZqcx5miyYAoI51
uuQKumonvVz9rqDJlv7PafO6iQEiBBABAgAMBQJOHJyTBQMAEnUAAAoJEJcQuJvK
V618Bs8IAK6QuhbB56UdUcZivWgyQs39RtJZeFvPFzIkWoEJtVEhT+MkqIAq0jma
7ABcs/pDT5wOHxasENyoMkgAQNNPviDDwwth4ITrA3MkjmUWieXTgm/SFZXk+ibI
3XncZR/u+7UGSFrnrZnVk9JV9771vjGaQV/xyGJyzAlQ7LaSPpBiMjz7D1KbAtta
0JCrerYlTneLDlCfHMn7mihlmS3dZpn2H6D1O8fhZqrfLyBWVT6dAL0I9KZNf5nI
gxyz0ZzJT2TG2f8pOiMJMCWBFbeYexI+6OdhmCghoiuLgMYt3w0vh4+y4OwBhwRb
tQNOVWcVZ3i1gktvH/fX3PIVuHuqypO0JUVyaWMgV2lsZm9uZyA8ZXJpY0BkeW5h
bWljc3RyaXBlLmNvbT6JAHwEEBECADwFAk1ZmCQHCwkIBwMCCgIZABkYbGRhcDov
L2tleXNlcnZlci5wZ3AuY29tBRsDAAAABR4BAAAABBUICQoACgkQvbeFpHWitKsV
mQCbBRmfC/3Ig/kfY505WE7vIUBcLBsAn0fqI0jf8aJhB2NEK+QtHMEU+jDliQEi
BBABAgAMBQJOPuZ9BQMAEnUAAAoJEJcQuJvKV618u5kH/A+4SI93yATvGWRO/ZaK
9XYJ/uiC8DYsK4eOiEhpdfbEA0G9krqoQxCcvQhP5traYJPGX8doLXbnLbXqTMKr
B4WKQEn9T0wwNDtya6rlATLR+bfQpTWt/Ij4n9wx+hFGP3Bv0b3rpTArMaiB55KX
05ZpsrdIBibcv6nr3pG0H4boXaPe2/3f8nVqawAA/qw0yeF9xPgwO0Ylhav7/7OJ
AfEOjuVuhXw28RKaAsdmmC25vn4JeCWA8TSWBhiNmTUAANGhVK7OtpQH60SzRtci
ntKj5FdvMuOvEmWcEMj23NZRSysLGIo4MKctSaXiB8h8CIH/eYOOzeKlUEdGOxxY
zMS0LkVyaWMgV2lsZm9uZyA8ZXdpbGZvbmdAdHJpbG9neWludGVyYWN0aXZlLmNv
bT6JAHwEEBECADwFAlA2oDUHCwkIBwMCCgIZARkYbGRhcDovL2tleXNlcnZlci5w
Z3AuY29tBRsDAAAABR4BAAAABBUICQoACgkQvbeFpHWitKt3/wCg6ebALQQ2qEcM
nGEf1k3TdOLQo5EAn3vq5HbDIpIOVkr10npAytOQvBVZiQEiBBABAgAMBQJQxEoO
BQMAEnUAAAoJEJcQuJvKV618vd4IAI+0rO0sbCyY5KhfayQJIHEBPteFNtTDODpv
XqA0pH9gswP/nVJiYY6YXOZUHc9zf4BtjMpXL7Bd060eZOTnPLwiQdCOpkVqdYh/
HQoXXW4upD4SCi4hkSxQUo9qET7ru64dB9OV4QNR69T1UkaQQkJpV2HGs7cNiWeP
Eb2Wnkwn2E31StxEkLirrg6ifE6GPw9CXOQhKGVWmSXaEJii5pwAOzD8bCqBvonQ
XEhW5EmdpdPEZqbS3sHimHeWdF21leXr8uSmQ2v03KrzQYrHIxNbIy5Nj/LH9U1V
hb8WrqmHtwSPxkyoH2d3qKPvSr5eGoonoVsnMsxbtlQirTy5VgW5Ag0EQkr73RAI
APZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mU
rfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VH
MGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2
azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMh
LLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+c
fL2JSyIZJrqrol7DVekyCzsAAgIIAIdM7RLRJ04s+vnhd35mTWxP5AVlYBs0uvfp
CcyjsRGCf7wZCfXPqDYEdNF5OIz4TTleO2TFGeTj2eNJRSF/+8nmsBMjq8chnCrF
8bA1mRrVcj02JdoIbZhvYIvY2QpfzOu3DUw5/B35wKm5h5uvW9RW5VYq0efc+1X9
sH12Mu11+4S0JKjdd0TpV6R74iLQ6WSFrzZ955DP1weZjqIbERKwpZDimYs8CcKq
nL2qX3YFxnnqelUNcKUvebLJghgTLVbMkWbUPrzncmr0Pnj025iDK3IgGGTD0PkT
HiBJn6IvkgvpHbuF2eUSXnn72tkK1xbzzd9I59ZsZSKi7xBhQYGJAEwEGBECAAwF
AkJK+90FGwwAAAAACgkQvbeFpHWitKuX1wCeNUHHfepvnoVVJMohVdSlgl2sKEcA
mQHsjcumlg3yYUA15VJdV00CwcYQ
=AhoQ
-----END PGP PUBLIC KEY BLOCK-----

Cert is ordered, waiting for issue

Thanks for this and for resolving T107060 @BBlack. If I can get you information on changing to https sooner than 10/7, I will.

I'm still a bit worried about the timeline here. We don't have firm deadlines, but presenting a plan on Oct 7 doesn't mean being ready to make the switch on Oct 7.

I see your concern. This may be an ignorant question, but would it be theoretically possible for us to take the benefactorevents.wikimedia.org page down after the event on 10/1, and not put it back up until the SSL cert is in place? I will have to confirm with @CaitVirtue that this works for her, but if every other subdomain is https at that point, that could be a temporary solution.

I would want to leave it up for one week post-event, to allow for donations
that inevitably trickle in during the days following the event, but it
would be fine with me to take it down after that. We will likely not need
it again until the 15th Birthday celebrations in January.

Caitlin Virtue
Director of Development
Wikimedia Foundation
(415) 839-6885 x6733
cvirtue@wikimedia.org
www.wikimediafoundation.org

*Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment. Donate.
https://donate.wikimedia.org/*

@EWilfong_WMF - cert/key info sent via email. Please respond there if there any technical issues with accessing the data...

RobH mentioned this in Unknown Object (Task).Jul 7 2016, 6:17 PM