Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
More help with SELF_SIGNED_CERT_IN_CHAIN and npm (npmjs.org)
29 points by seldo on March 1, 2014 | hide | past | favorite | 9 comments


After reading both blog posts, I still didn't know exactly what the heck actually happened, so I downloaded node.js 0.11.9 (released in November 2013 but not the latest version) and ran "npm config get ca" to see what npm's default trusted certificate store used to be. There were four certificates:

• an "npm Certificate Authority" X.509v1 certificate valid from 2011-09-05 (an X.509v1 cert in 2011? srsly?)

• two of GlobalSign's Root CA certificates

• a GlobalSign subordinate CA certificate

What I'm guessing happened is that the certificate https://registry.npmjs.org used a long time ago was signed by that "npm Certificate Authority" certificate. Then they switched to a signed-by-GlobalSign certificate. Then, two days ago, they switched to an EV certificate from DigiCert, and that's when all hell broke loose for people not using the latest version of npm because not-latest versions of npm would only trust certificates that chained up to GlobalSign's Root CAs or the "npm Certificate Authority."

If I'm right about what happened, then the brunt of this kerfuffle might've been avoided by making ca="" the default in npm releases as soon as the GlobalSign-signed certificate hit production and everyone was happy that it was working. Hindsight is 20/20 like that, though.


That is pretty much exactly correct.


I'm worried about this - they state:

  We are rolling back to the older cert now, but since the registry is distributed 
  by a global CDN this process is slower than we’d like, and we don’t want 
  to break things (further) by rushing the process.
If they roll back to the older cert, every install of npm that was "fixed" via the steps in the last post, or updated to latest (node v10.0.26/npm v1.4.4) will break. Perhaps I am missing something but it sounds as though they intend to follow up breaking most npm installs by breaking most npm installs yet again.


That's not correct. The latest npm (and any npm configured with ca="") will use the CA baked into your operating system's version of OpenSSL. Our old cert, from GlobalSign, works just fine with OpenSSL.


So you're reverting to a cert that is not the old self-signed cert?


Correct. It is a GlobalSign cert that was donated to the Node.js project. Once we became a company we had to stop using it, both from an abundance of caution, security wise, since we were not the only ones who had the cert, but also because it wasn't right to be using a free cert for our new, for-profit entity.

But moving to our new, self-owned cert in a way that broke anything was avoidable, and a huge error on our part.


I see. And that old cert will work with old npm clients?

Additionally, what are your thoughts on signing the digicert CA with the npm CA as mentioned here [1], thus fixing old clients and avoiding another cert switch?

1. https://news.ycombinator.com/item?id=7322970


Any npm downloaded after ~August of 2012, which is when the GlobalSign CA was added to the client:

https://github.com/npm/npmconf/commit/d7ef61c8d9ae87f39482c5...

I believe we considered adding the npmCA and dismissed it, but it has been a long week and I can no longer recall why. I will bring it up and post an update here next week.


Thanks for the updates and finding the time to post during what's certainly been a hectic day.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: