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.
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.
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?
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.
• 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.