Hacker News new | ask | show | jobs
by emily37 4487 days ago
If anyone is wondering what the actual change was:

It looks like the npm registry used to have a certificate signed by npm's own CA, and existing npm clients only trust that CA by default, not the normal list of verisign, digicert, etc. (Trusting versign et al would defeat the point of using their own CA.) The signing key for that CA is pretty darn important, and maybe there are entities other than npm, inc who might know it (i.e. nodejitsu).

So npm, inc rolled out a new cert that looks to be signed by digicert, but existing clients don't trust Digicert until you explicitly configure them to.

I was thrown off by the SELF_SIGNED_CERT_IN_CHAIN error; I expected some error about an untrusted root CA if the problem was that npm clients didn't trust digicert, but apparently SELF_SIGNED_CERT_IN_CHAIN is what OpenSSL returns when the root CA isn't loaded.

2 comments

If the clients trust the npm CA, can't they just sign the digicert CA with that CA and include it in the certificate chain provided by the server? That way the chain would be:

    npm CA -> digicert CA -> any other intermediates -> server cert
Clients that only trust the digicert CA (and other standard CAs) will see that and accept it because they trust the digicert CA, and clients that trust the npm CA will trust the cert also, allowing both old and new clients to work. Once (almost) everyone has upgraded, the npm root CA can be removed from the chain presented by the server. Am I missing something here?

Edit: It looks like what I'm missing is that you'd need the private key of the digicert CA to generate the request to sign with the npm CA. I was thinking about how CAs have been migrated in the past (e.g. equifax to geotrust global CA). It looks like it won't work in this case.

Edit2: Actually, it appears to work after all. I just tested with the openssl ca command, and you give it -ss_cert instead of -in for the certificate to sign a certificate instead of a request.

> Am I missing something here?

A sense of arrogance that precludes understanding x509 infrastructure before you roll out a world-breaking change.

Lets apply a bit of sense here: this was a failure of judgement, not arrogance. It's perhaps easier to picture the npm developers as maniacal villains, cackling as they wield destruction among us. But that's not the case with them, just as it is pretty much never the case with project developers.
I just picture them as cowboy coders not really aware of what it takes to build and maintain software for large enterprises, which is, unfortunately, their stated mission.
Let any developer who has never pushed an update with unintended side effects raise their hand.

This mistake was, in hindsight, a clear error in judgement. It highlights missing steps in their change deployment process. And I expect them to learn from it, as the larger Node community has shown they can learn from mistakes.

Part of joining the ranks of "enterprise"-grade projects is first being an aspiring project, and part of that is learning a lot. Anyone who expects that to happen without a few bumps is naive.

I agree with you. Everyone makes a mistake once in a while. To be successful, you should learn from it.
I don't think people think they're arrogant. I think people find them unsuited to the task at hand. If you felt that way already, this incident would have been another nail in the coffin.
Indeed! Don't forget kids, don't ever do anything if you're not already an expert.
Yes, that sounds about right. Spend the time necessary to understand before you inflict your lack of understanding on the world.
That kind of chain doesn't seem to be ubiquitously accepted. I built up something similar at https://ssltest.greenapes.com:4443. There is a self-signed CA signing a trusted CA (StartCom), which in turn is signing a valid certificate for the hostname.

The chain is accepted by Firefox and Chrome with NSS, but Safari (and Chrome on OSX) gives a self-signed warning message. I asked AGL and he thinks that it should be valid: https://twitter.com/giovannibajo/status/439746540249567232

So it looks like it should work in theory, but in practice, even if npm had attempted this, it wouldn't work on Mac.

I was thrown off by the SELF_SIGNED_CERT_IN_CHAIN error; I expected some error about an untrusted root CA if the problem was that npm clients didn't trust digicert, but apparently SELF_SIGNED_CERT_IN_CHAIN is what OpenSSL returns when the root CA isn't loaded.

All root CAs are self-signed, that's what makes them root. What overrides the self-signing being an error is it being listed in the CA list available to the client which is updated out of band.