SSL certificate issues

[jbergstroem]

A few people have reported issues regarding to ssl certificates. I triaged it to lacking SNI support. According to Wikipedia the only client that seems remotely close would be wget, with the first supported release roughly three years ago (unless some distros compile clients specifically without certain features of x509).

The way to solve this is adding an additional IP for each SSL host we use (which in practise would mean one for iojs and one for nodejs) or moving SSL termination to Cloudflare which would require us to upgrade to a pro or business account.

I'm not sure how widespread this issue is, but either of above solution should be pretty easy to implement.

[Starefossen]

Here is the SSL Server Test report for nodejs.org, at least on the browser side of things almost all of them support SNI.

Also, I am pretty sure that, if configured correctly, non-SNI capable clients will be able to connect to the default vhost.

[jbergstroem]

connecting to the default vhost won't help them since that would return the wrong certificate for iojs.org (*.nodejs.org)

[jbergstroem]

It looks like the vm's at travis-ci.org seems to have a too old version of wget.

[ljharb]

This issue affects all travis-ci VMs that aren't in their new "container" format (ie, sudo: false is the new one) - and it may indeed affect the new ones also, but I haven't checked.

[Starefossen]

So the issue is somewhat limited to old wget-users downloading io.js binaries? Mostly through travis ci which there apparently exists a workaround for?

[jbergstroem]

That'd be my conclusion based on wikipedia. We for instance have this issue on our centos5 slaves; but again limited to wget.

[rvagg]

I've just tried out the new "Floating IP" DO feature on the web server, it now has 45.55.98.129 pointing to it, but the server doesn't appear to be aware of this, it's obviously just a datacenter routing thing rather than going all the way down to the server like it can with AWS. So I'm not sure we're going to be able to do the separate IP thing unless we have a separate server which is a pain since we've gone through the process of integrating everything.

[jbergstroem]

@rvagg doesn't that just mean we can assign another ip with network setup? I can try.

[rvagg]

you can try I guess, I have left it on there for this kind of tinkering

[jbergstroem]

So, the anchor ip you set up locally is where we want to point iojs (or nodejs, but i prefer messing up the prior). Not sure how to automate all of this ansible though. I'll look at that first.

[jbergstroem]

OK, this likely needs to happen:

1. cloudflare: upgrade iojs.org to a business account and upload the certificate
2. cloudflare: change iojs.org to listen at the anchor public ip address
3. nginx: make iojs listen at the internal anchor address
4. (probably optional) nginx: make nodejs listen at the default public address

[rvagg]

I recently downgraded iojs.org to a personal account because I discovered that my personal credit card was being charged $200/month for the pleasure of it being a business account...

[ljharb]

@rvagg how recently? Perhaps that's what triggered these SSL issues.

[rvagg]

pretty sure it's unrelated, we didn't lose any features that we were using as far as I know

[jbergstroem]

As far as i know, going from business to free or using business won't affect SNI. What we need is an enterprise account to get our own ip.

[ljharb]

ah, gotcha

[Trott]

@nodejs/build @jbergstroem Should this remain open?

[sam-github]

Closing as stale, but if anyone wants to take this up feel free to reopen.