Bugzilla – Bug 1000036
devel:languages:nodejs/nodejs: CA certificates broken on SLE11
Last modified: 2019-12-11 20:19:44 UTC
After https://build.opensuse.org/request/show/424285 was added, anything using the system CA certificate directory is broken on SLE_11_SP4 (simple test: 'npm ping', which fails with 'Error: unable to get local issuer certificate'). npm is unable to access the registry, and anything in Node making SSL connections fails. This appears to be because the certificate hashing algorithm changed between openssl 0.9.8 (shipped in SLES 11) and 1.0+ (1.0.2 is bundled with Node.js) -- see the -subject_hash and -subject_hash_old options in x509(1ssl). Running npm under strace confirms this: ==== SLES 11 ==== npm http request GET https://registry.npmjs.org/-/ping?write=true stat("/etc/ssl/certs/4a6481c9.0", 0x7fffdc5e9fb0) = -1 ENOENT (No such file or directory) stat("/etc/ssl/certs/73af33e2.0", 0x7fffdc5e9fb0) = -1 ENOENT (No such file or directory) ==== Leap 42.1 ==== stat("/etc/ssl/certs/4a6481c9.0", {st_mode=S_IFREG|0444, st_size=1354, ...}) = 0ches userconfig) ==== On 42.1, that is a symlink to GlobalSign_Root_CA_-_R2.pem, which is indeed the CA for registry.npmjs.org. On SLES 11, however, the hash link is "111e6273.0", which matches the "subject_hash_old": ==== leap421:/etc/ssl/certs $ openssl x509 -noout -subject_hash -subject_hash_old -in GlobalSign_Root_CA_-_R2.pem 4a6481c9 111e6273 ==== Workarounds include copying the CA certificate directory from a Leap/SLE12 machine, or copying the SLE11 certs to a newer machine, running c_rehash, and copying back (optionally to a new directory we point node at); this is better than disabling 'strict-ssl' in npm but not great. Since the system CA cert dir from SLE11 is not usable by the openssl bundled with Node, it's probably best to disable the "use-system-ca-store" patch for SLE11 and let Node.js use its built-in bundle. I'll submit a request in OBS if this is an acceptable solution.
If the patch is reverted, then the CA store that is used is upstream's bundled CA blob and system CA store is ignored, which is not very good. I think the best way would be to patch OpenSSL shipped with NodeJS, just for the SLE11 people, so that that the certificate hash function is the same as in the old version of OpenSSL. Now I'm not certain of the amount of work required for this, but if it's not too much, then this may be better option. But then this has problems because SLE11 apparently has OpenSSL 1.x in its security module. So... Another option would be to ship c_rehash binary from NodeJS in-tree version in libexec path that then can be used by users still on SLE11 and affected to relink things.
We have already a method for that with the SECURITY Module and its openssl1 version. If that openssl1 package is installed, it will create both hashes.
Thank you. Then the solution is add depend on openssl1 for SLE11.
I just tested enabling the SLE11-Security-Module repo and installing the 'openssl1' package, and the openssl1 hashes were NOT automatically created. The %post/%postun scripts of the openssl-certs package will generate the hashes if openssl1 is already present, but there's no trigger to do this upon installation of openssl1. (Doing a force reinstall of openssl-certs does generate both styles of hashes.) Because of this, just having nodejs depend on openssl1 won't directly solve the issue, and creates new ones -- how do we tell users to enable the SLE11-Security-Module, let alone reinstall openssl-certs? If someone just searches OBS for nodejs and then attempts to install the package from d:l:nodejs, it will fail with missing deps of openssl1. This would be a reasonable solution, if not for those issues...
Yes, I can confirm this problem. Installing openssl1 is insufficient. c_rehash1 is not run by openssl1 by default. Marcus, what is the proper procedure here? Is this 1. a bug in openssl1, or 2. another package is missing, or 3. users of openssl1 should run c_rehash1 manually?
The c_rehash script of openssl will also generate openssl1 hashes when run and the openssl1 commandline tool is installed. openssl-certs %post runs this script during install/update, but you can also run it if needed. hmm.
(In reply to Marcus Meissner from comment #6) > The c_rehash script of openssl will also generate openssl1 hashes when run > and the openssl1 commandline tool is installed. > > > openssl-certs %post runs this script during install/update, but you can also > run it if needed. > > hmm. imho the only clean solution is to call c_rehash1 in the %post of openssl1. having other packages call it, is putting the responsibility into the wrong places.
we can also do that additionaly, yes.
Andrew, the nodejs package is now fixed in the devel project. Bug will remain opened until it's fixed in the openssl1 package. Until then, the workaround is to run c_rehash manually after installing nodejs if it cannot find some certificates.
fixed when openssl1 gets through the QA process.
SUSE-SU-2017:0855-1: An update that solves three vulnerabilities and has one errata is now available. Category: security (moderate) Bug References: 1000036,1009528,1022085,1022086 CVE References: CVE-2016-7055,CVE-2017-3731,CVE-2017-3732 Sources used: SUSE Linux Enterprise Module for Web Scripting 12 (src): nodejs4-4.7.3-14.1 SUSE Enterprise Storage 4 (src): nodejs4-4.7.3-14.1
openSUSE-SU-2017:0941-1: An update that solves three vulnerabilities and has one errata is now available. Category: security (moderate) Bug References: 1000036,1009528,1022085,1022086 CVE References: CVE-2016-7055,CVE-2017-3731,CVE-2017-3732 Sources used: openSUSE Leap 42.2 (src): nodejs4-4.7.3-5.3.1
This is an autogenerated message for OBS integration: This bug (1000036) was mentioned in https://build.opensuse.org/request/show/636889 42.3+Backports:SLE-12 / nodejs8
This is an autogenerated message for OBS integration: This bug (1000036) was mentioned in https://build.opensuse.org/request/show/642571 42.3+Backports:SLE-12 / nodejs8
This is an autogenerated message for OBS integration: This bug (1000036) was mentioned in https://build.opensuse.org/request/show/649577 Backports:SLE-12-SP2 / nodejs8
SUSE-SU-2019:14246-1: An update that fixes 118 vulnerabilities is now available. Category: security (important) Bug References: 1000036,1001652,1025108,1029377,1029902,1040164,104105,1042670,1043008,1044946,1047925,1047936,1048299,1049186,1050653,1056058,1058013,1066242,1066953,1070738,1070853,1072320,1072322,1073796,1073798,1073799,1073803,1073808,1073818,1073823,1073829,1073830,1073832,1073846,1074235,1077230,1079761,1081750,1082318,1087453,1087459,1087463,1088573,1091764,1094814,1097158,1097375,1097401,1097404,1097748,1104841,1105019,1107030,1109465,1117473,1117626,1117627,1117629,1117630,1120644,1122191,1123482,1124525,1127532,1129346,1130694,1130840,1133452,1133810,1134209,1138459,1140290,1140868,1141853,1144919,1145665,1146090,1146091,1146093,1146094,1146095,1146097,1146099,1146100,1149323,1153423,1154738,1447070,1447409,744625,744629,845955,865853,905528,917607,935856,937414,947747,948045,948602,955142,957814,957815,961254,962297,966076,966077,985201,986541,991344,998743 CVE References: CVE-2013-2882,CVE-2013-6639,CVE-2013-6640,CVE-2013-6668,CVE-2014-0224,CVE-2015-3193,CVE-2015-3194,CVE-2015-5380,CVE-2015-7384,CVE-2016-2086,CVE-2016-2178,CVE-2016-2183,CVE-2016-2216,CVE-2016-5172,CVE-2016-5325,CVE-2016-6304,CVE-2016-6306,CVE-2016-7052,CVE-2016-7099,CVE-2017-1000381,CVE-2017-10686,CVE-2017-11111,CVE-2017-11499,CVE-2017-14228,CVE-2017-14849,CVE-2017-14919,CVE-2017-15896,CVE-2017-15897,CVE-2017-17810,CVE-2017-17811,CVE-2017-17812,CVE-2017-17813,CVE-2017-17814,CVE-2017-17815,CVE-2017-17816,CVE-2017-17817,CVE-2017-17818,CVE-2017-17819,CVE-2017-17820,CVE-2017-18207,CVE-2017-3735,CVE-2017-3736,CVE-2017-3738,CVE-2018-0732,CVE-2018-1000168,CVE-2018-12115,CVE-2018-12116,CVE-2018-12121,CVE-2018-12122,CVE-2018-12123,CVE-2018-20406,CVE-2018-20852,CVE-2018-7158,CVE-2018-7159,CVE-2018-7160,CVE-2018-7161,CVE-2018-7167,CVE-2019-10160,CVE-2019-11709,CVE-2019-11710,CVE-2019-11711,CVE-2019-11712,CVE-2019-11713,CVE-2019-11714,CVE-2019-11715,CVE-2019-11716,CVE-2019-11717,CVE-2019-11718,CVE-2019-11719,CVE-2019-11720,CVE-2019-11721,CVE-2019-11723,CVE-2019-11724,CVE-2019-11725,CVE-2019-11727,CVE-2019-11728,CVE-2019-11729,CVE-2019-11730,CVE-2019-11733,CVE-2019-11735,CVE-2019-11736,CVE-2019-11738,CVE-2019-11740,CVE-2019-11742,CVE-2019-11743,CVE-2019-11744,CVE-2019-11746,CVE-2019-11747,CVE-2019-11748,CVE-2019-11749,CVE-2019-11750,CVE-2019-11751,CVE-2019-11752,CVE-2019-11753,CVE-2019-11757,CVE-2019-11758,CVE-2019-11759,CVE-2019-11760,CVE-2019-11761,CVE-2019-11762,CVE-2019-11763,CVE-2019-11764,CVE-2019-13173,CVE-2019-15903,CVE-2019-5010,CVE-2019-5737,CVE-2019-9511,CVE-2019-9512,CVE-2019-9513,CVE-2019-9514,CVE-2019-9515,CVE-2019-9516,CVE-2019-9517,CVE-2019-9518,CVE-2019-9636,CVE-2019-9811,CVE-2019-9812,CVE-2019-9947 Sources used: SUSE Linux Enterprise Server 11-SP4-LTSS (src): MozillaFirefox-68.2.0-78.51.4, MozillaFirefox-branding-SLED-68-21.9.8, firefox-atk-2.26.1-2.8.4, firefox-cairo-1.15.10-2.13.4, firefox-gcc5-5.3.1+r233831-14.1, firefox-gcc8-8.2.1+r264010-2.5.1, firefox-gdk-pixbuf-2.36.11-2.8.4, firefox-glib2-2.54.3-2.14.7, firefox-gtk3-3.10.9-2.15.3, firefox-harfbuzz-1.7.5-2.7.4, firefox-libffi-3.2.1.git259-2.3.3, firefox-libffi-gcc5-5.3.1+r233831-14.1, firefox-pango-1.40.14-2.7.4, mozilla-nspr-4.21-29.6.1, mozilla-nss-3.45-38.9.3 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.