distributions: The certificate for deb.nodesource seems to be expired

We are aware of the situation and are actively working to fix it, thank you for your patience.

On the client (Ubuntu), doing this prior to install allowed me to pass through the certificate error: sudo apt install ca-certificates

Edit: might need apt update first

For Debian buster, updating the libgnutls30 package appears to fix the certificate verification.

apt-get update; apt-get install libgnutls30

I saw this from a docker build. I added this as a workaround so apt update would work again.

RUN apt-get update ; apt-get install ca-certificates \
    && apt-get update \
    && apt-get install -y \
...

curl -fsSLk https://rpm.nodesource.com/setup_12.x | bash - could be a good short-term solution (-k disables the client-side SSL verification).

For Debian buster, updating the libgnutls30 package appears to fix the certificate verification.

apt-get update; apt-get install libgnutls30

This solution worked for us.

In my image build workflow, I was able to workaround it like this:

# Workaround for: https://github.com/nodesource/distributions/issues/1266
mv /etc/apt/sources.list.d/nodesource.list /etc/apt/sources.list.d/nodesource.list.disabled
apt-get update
apt-get -y upgrade
apt-get  install -y \
    ca-certificates \
    libgnutls30 
mv /etc/apt/sources.list.d/nodesource.list.disabled /etc/apt/sources.list.d/nodesource.list

After reading 100+ comments, that one worked for me . Thanks for https://github.com/nodesource/distributions/issues/1266#issuecomment-931822235

      # Update apt and install newest version of CA certificates
      - run: apt-get -y update || apt-get install -y ca-certificates && apt-get upgrade -y ca-certificates

      # Remove invalid SSL (2021-09-30)
      - run: rm /etc/ssl/certs/2e5ac55d.0
      - run: rm /etc/ssl/certs/12d55845.0
      - run: rm /etc/ssl/certs/DST_Root_CA_X3.pem
      - run: sed -i '/mozilla\/DST_Root_CA_X3.crt/d' /etc/ca-certificates.conf

      # Update CA certificates
      - run: update-ca-certificates --fresh

Just FYI: disabling certification verification globally is not a solution and makes you vulnerable to attacks in this area in the future. You basically bypass the reason HTTPS and certificates exist this way.

On the client, doing this prior to install allowed me to pass through the certificate error: sudo apt install ca-certificates

Unfortunately that did not work in my case since I was already at latest.

As temp solutions works at Ubuntu20

---

$curl -s http://deb.nodesource.com/gpgkey/nodesource.gpg.key | apt-key add -

$ sudo sh -c “echo deb http://deb.nodesource.com/node_14.x focal main > /etc/apt/sources.list.d/nodesource.list” $ sudo apt-get update $ sudo apt-get install nodejs

---

I hope it will works for other distros and nodeversions Http not https

This unified solution worked for our case. Thanks to @spkane @rogerd330

RUN mv /etc/apt/sources.list.d/nodesource.list /etc/apt/sources.list.d/nodesource.list.disabled \
    && apt-get update \
    && apt-get -y upgrade \
    && apt-get  install -y ca-certificates libgnutls30 \
    && mv /etc/apt/sources.list.d/nodesource.list.disabled /etc/apt/sources.list.d/nodesource.list \
    && apt-get update \
    && apt-get install -y nodejs 

We found this AWS support article from today that fixed the issue for us.

https://aws.amazon.com/premiumsupport/knowledge-center/ec2-expired-certificate/

We manually had to update our instances.

Can we please stop recommending falling back to plaintext http? The correct fix here is to ensure that client CA certificates are up to date, and half-baked workarounds usually cause more problems in the long run than they solve. The specific details vary from one distro to another, but usually involve updating the ca-certificates package.

For everything to work smoothly (particularly gnutls-based clients like apt-get), the ISRG Root X1 (new Let’s Encrypt root) certificate needs to be present in your trust store and the DST Root CA X3 (old Let’s Encrypt root) needs to be removed. If the DST cert is present, GnuTLS tries to validate the cross-signature, fails because the DST cert is expired, and then marks the entire chain as untrusted even though the ISRG cert is itself trusted.

Pulling in what others have done, I was able to get it to work like this for debian stretch:

# Update apt and install CA certificates
apt-get update && apt-get install -y ca-certificates

# Remove invalid SSL (2021-09-30)
rm /etc/ssl/certs/2e5ac55d.0
rm /etc/ssl/certs/12d55845.0
rm /etc/ssl/certs/DST_Root_CA_X3.pem
sed -i '/mozilla\/DST_Root_CA_X3.crt/d' /etc/ca-certificates.conf

# Update CA certificates
update-ca-certificates --fresh

This seems to be happening again: https://deb.nodesource.com/node_16.x/pool/

I’d love to hear a “non-temporary” fix update on this.

This was causing by BitBucket pipelines to fail and the following changes seem to have fixed it:

Original steps: - curl -sL https://deb.nodesource.com/setup_12.x | bash - - apt-get install -y nodejs

New Steps: - apt-get update - apt-get install -y ca-certificates libgnutls30 - echo ‘-k’ > ~/.curlrc - curl -sL https://deb.nodesource.com/setup_12.x | bash - - apt-get install -y nodejs

Same. I got past the SSL issue with curl -fsSLk http://deb.nodesource.com/setup_12.x | bash but now I see:

## Your distribution, identified as "stretch", is not currently supported, please contact NodeSource at https://github.com/nodesource/distributions/issues if you think this is incorrect or would like your distribution to be considered for support

The “September 30” syndrome?

Can someone provide an update regarding this issue? The previous one was 4 hours ago. Even if you tell CURL to use HTTP or ignore the cert error, it seems that the setup is claiming numerous platforms are unsupported.

For those wondering why updating ca-certificates solves the problem, the old Lets Encrypt root certificate expired, and you need to download a new one.

In an up-to-date browser, you should be able to load this page without a problem: https://deb.nodesource.com/setup_12.x But not on a server with out-of-date certificates:

$ curl https://deb.nodesource.com/setup_12.x
curl: (60) SSL certificate problem: certificate has expired
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Along with this problem, if I bypass the SSL problem, still I can’t install in Amazon Linux 1 getting an error like:

## Your distribution, identified as "system-release-2018.03-0.2.noarch", is not currently supported, please contact NodeSource at https://github.com/nodesource/distributions/issues if you think this is incorrect or would like your distribution to be considered for support

Whereas it was working 2 hours ago.

This fixed it for me in Debian:

RUN apt-get update
RUN apt-get upgrade ca-certificates -y
RUN curl -fsSL https://deb.nodesource.com/setup_14.x | bash -
RUN apt-get install -y nodejs

Using Debian as root. This particular comment saved my pipeline:

apt-get install openssl ca-certificates

rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
update-ca-certificates

curl -fsSL https://deb.nodesource.com/setup_14.x | bash - # No longer throws an error.
apt-get install -y nodejs

This fixed my CircleCI pipeline that was running on the ubuntu-2004 image. Thanks @german-e-mas!

This works for me also. Others don’t.

For debian 9 based docker images the following seems to be a minimal workaround to solve a problem: apt update && apt install libssl1.0.2 libgnutls30

Following this exact message (removing the bad cert and forcing Ubuntu to update CA certificates) hotfixed the issue and saved the night for us (Xenial): https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/324

There is a workaround.

from curl -sL https://deb.nodesource.com/setup_14.x | bash - to curl -sL https://deb.nodesource.com/setup_14.x | sed ’s|https://|http://|’ | bash -

Any solution for Amazon Linux 2 ? 😃 I still have the certificate issue and when i try to bypass it, i have the following message: Your distribution, identified as "system-release-2-12.amzn2.x86_64", is not currently supported, please contact NodeSource at https://github.com/nodesource/distributions/issues if you think this is incorrect or would like your distribution to be considered for support

Using Debian as root. This particular comment saved my pipeline:

apt-get install openssl ca-certificates

rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
update-ca-certificates

curl -fsSL https://deb.nodesource.com/setup_14.x | bash - # No longer throws an error.
apt-get install -y nodejs

For those looking for a deeper understanding of why this happened, user schoen (“Former Certbot engineer, 2015-2020”) has a great explanation in this comment:

https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/497

I got our system, on Amazon, working with this workaround (I had experience the cert and unsupported platform errors):

Old commands: curl -sL https://rpm.nodesource.com/setup_8.x | sudo -E bash - sudo yum -y install nodejs

New commands: echo ‘-k’ > ~/.curlrc curl -sL https://rpm.nodesource.com/setup_8.x --output setup.sh sed -i ‘s/https/http/gi’ setup.sh sudo -E bash setup.sh echo ‘sslverify=false’ | sudo tee -a /etc/yum.conf sudo yum -y install nodejs

Hello there. Updating ca-certificates on my base Docker image fixed the issue in my pipelines. Hope this helps !

While folks don’t sort this out, we disabled Nodesource’s repository and installed it directly from somewhere else:

mkdir /tmp/node && \
    cd /tmp/node && \
    curl -o node.tar.xz -sSL https://nodejs.org/dist/v16.10.0/node-v16.10.0-linux-x64.tar.xz && \
    tar -C /usr/local --strip-components 1 -xvzf node.tar.xz && \
    rm -rfv /tmp/node

@gonzaloaune, same here

Problem with Amazon Linux 1

I using Amazon Linux 2018.03 release Added below commands to configs before execute curl -L https://rpm.nodesource.com/setup_12.x | sudo bash - work for me. sudo yum update ca-certificates sudo yum -y install https://cdn.amazonlinux.com/patch/ca-certificates-update-2021-09-30/ca-certificates-2018.2.22-65.1.24.amzn1.noarch.rpm

Reference: https://aws.amazon.com/premiumsupport/knowledge-center/ec2-expired-certificate/

This fixed it for me in Debian:

RUN apt-get update
RUN apt-get upgrade ca-certificates -y
RUN curl -fsSL https://deb.nodesource.com/setup_14.x | bash -
RUN apt-get install -y nodejs

This is what fixed for me.! The certificates were not updated with the install. needed to do a upgrade

Using Debian as root. This particular comment saved my pipeline:

apt-get install openssl ca-certificates

rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
update-ca-certificates

curl -fsSL https://deb.nodesource.com/setup_14.x | bash - # No longer throws an error.
apt-get install -y nodejs

This fixed my CircleCI pipeline that was running on the ubuntu-2004 image. Thanks @german-e-mas!

We found this AWS support article from today that fixed the issue for us.

https://aws.amazon.com/premiumsupport/knowledge-center/ec2-expired-certificate/

We manually had to update our instances.

I can confirm this works.

@Ranarxhag: On Amazon Linux 2, you can’t remove the CA from trust easily, because it’s included in p11-kit, and marked read-only (so the sudo trust anchor --remove command won’t affect it). The easiest way I found was to put the DST root CA X3 cert in the blacklist.

1. Find yourself a DST_Root_CA_X3.pem (it’s only about 20 lines, but not pasting here for brevity) - on Amazon Linux I couldn’t find an “extracted”/separate version of this file; it seems they only include the built ca-bundles
2. Put that in /etc/pki/ca-trust/source/blacklist/DST_Root_CA_X3.pem
3. Run sudo update-ca-trust

Don’t try this at home, kids (redhat variants):

echo "sslverify=false" >> /etc/yum.conf
echo "-k" > $HOME/.curlrc
curl -sLk https://rpm.nodesource.com/setup_14.x | bash -

EDIT: Please definitely prefer to update your ca-certs package over doing anything like this!

Installing ca-certificates tells me I’m on the newest version. But I can’t apt update the package list to get a newer version to install because node is making me fail the apt update. Any way to break this cycle of doom?

My note about workarounds being at risk of causing more problems than they solve also applies to curl’s -k flag, and especially to modifying .curlrc.

Same for RPM:

$ curl -fsSL https://rpm.nodesource.com/setup_12.x | bash -
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

UPDATE: Fixed with yum update ca-certificates

Guys, just need to update the ca-certificates from machine. The old certificate got untrusted, when it’s updated, the error get vanished:

If you are using AMI Linux 2:

sudo yum update ca-certificates

If you are using Ubuntu:

sudo apt update -y
sudo apt install libgnutls30 ca-certificates -y
sudo update-ca-certificates

https://github.com/nodesource/distributions/issues/1270#issuecomment-932130501

is how we solved the ssl cert issue.

apt-get upgrade -y ca-certificates has worked for me on some of the older python docker based images i.e. Debian “stretch”

This solved the problem for me on Amazon AMI Linux 2

sudo sed -i'' '/DST Root CA X3/,/\[p11-kit-object-v1\]/d' /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit 
sudo update-ca-trust

@dominics workaround worked very well on Amazon Linux, but there were a few other things that needed to be done if you’re doing this in a debian Docker container and not specifically working on Amazon Linux. After tinkering with it some, I discovered that we can get around the issue by simply forcing ca-certificates to update and running update-ca-certificates --fresh

For anyone who is in a similar situation, I used the following in my Dockerfile to get around this.

### TEMPORARY WORKAROUND FOR ISSUE https://github.com/nodesource/distributions/issues/1266

RUN apt-get -y update || echo "This is expected to fail."

RUN apt-get install -y ca-certificates
RUN rm -f /usr/local/share/ca-certificates/certificate.crt
RUN update-ca-certificates --fresh

Note the initial apt-get -y update || echo "This is expected to fail."

I had to add this otherwise my docker container would think it was already on the latest version of ca-certificates.

Furthermore, I had to add these lines in order to get that “expired” certificate to be recognized as valid again.

RUN rm -f /usr/local/share/ca-certificates/certificate.crt
# --fresh is needed to remove symlinks to no-longer-present certificates
RUN update-ca-certificates --fresh

Hope this helps. If anyone has any clarifications or adjustments to the above, please feel free to suggest them!

UPDATE: As it turns out, the certificate refresh isn’t even needed. Just forcing an update on ca-certificates is enough.

This was the final workaround

RUN apt-get -y update || apt-get install -y ca-certificates && apt-get update

Translated from https://github.com/tuna/issues/issues/1342#issuecomment-931412628:

This is because LE’s previous cross-root DST Root CA X3 expired at 22:00 on September 30. Please follow the table to upgrade the corresponding package to repair:

Ubuntu version	openssl	gnutls	ca-certificates
Precise(12.04)		Officially won’t fix
Trusty (14.04)	Please wait for the official fix	Officially won’t fix
Xenial (16.04)	libssl1.0.0 1.0.2g-1ubuntu4.20 or later	libgnutls30 3.4.10-4ubuntu1.9 or later	ca-certificates 20210119~16.04.1 or later
Bionic (18.04)		libgnutls30 3.5.18-1ubuntu1.5 or later	ca-certificates 20210119~18.04.2 or later
Focal (20.04)		Please wait for the official fix	ca-certificates 20210119~20.04.2 or later

Debian version	openssl	gnutls	ca-certificates
Stretch	libssl1.0.0 1.0.2u-1~deb9u5 or later	libgnutls30 3.5.8-5+deb9u6 or later
Buster		libgnutls30 3.6.7-4+deb10u5 or later

RHEL/CentOS version	ca-certificates
8	ca-certificates-2021.2.50-80.0.el8_4 or later
7	ca-certificates-2021.2.50-72.el7_9 or later
6	ca-certificates-2021.2.50-60.1.el6_10 or later

If you have difficulty obtaining the software package, you can use the following commands (from RHEL/CentOS 7 Fix for Let’s Encrypt Change) to temporarily fix with the problem:

trust dump --filter "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10" | openssl x509 | sudo tee /> etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem
sudo update-ca-trust extract

---

Possible solutions:

1. update package openssl / gnutls / ca-certificates:

sudo apt update
sudo apt install libgnutls30 ca-certificates
sudo update-ca-certificates

1. use HTTP rather than HTTPS in sources:

sudo sed -i 's|https://|http://|' /etc/apt/sources.list.d/nodesource.list  # at your own peril!

sudo sed -i 's|http://|https://|' /etc/apt/sources.list.d/nodesource.list  # change back

1. blacklist the root certificate (by RHEL/CentOS 7 Fix for Let’s Encrypt Change):

trust dump --filter "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10" | openssl x509 | sudo tee /etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem
sudo update-ca-trust extract

1. disable APT CA check (by https://github.com/nodesource/distributions/issues/1266#issuecomment-938408547):

echo "Acquire::https::Verify-Peer false;" | sudo tee -a /etc/apt/apt.conf.d/80ssl-exceptions  # at your own peril!
echo "Acquire::https::Verify-Host false;" | sudo tee -a /etc/apt/apt.conf.d/80ssl-exceptions

sudo rm -f /etc/apt/apt.conf.d/80ssl-exceptions  # change back

Work with that in my DockerFile

RUN curl -sL https://deb.nodesource.com/setup_12.x | sed ‘s|https://|http😕/|’| bash -
&& apt-get install -y nodejs

I had same problem on making from ubuntu:20.04 image. I was able to solve this my Dockerfile. This is temporary setting, purpose for inspection. (Many “RUN” will makes many image layers, not favorable.)

FROM ubuntu:20.04
RUN apt update && apt install -y curl ca-certificates
RUN update-ca-certificates
RUN curl -fsSL https://deb.nodesource.com/setup_lts.x | bash -
RUN apt install -y nodejs
RUN node -v

Hello ! Try all solutions above, but I still have the issue … anyone else ?

can confirm apt install ca-certificates fixed it for us

I was able to solve this by adding this to my dockerfile RUN apt-get update ; apt-get install ca-certificates
&& apt-get update
&& apt-get install -y

As mentioned in other comments, adding this to a build spec on AWS seems to fix the issues in CodeBuild: apt-get update apt-get install ca-certificates

Added those before installing node and it works again. Thanks to Florent Masson for suggesting it.

I didn’t read thru the 150+ comments, but on Ubuntu 20.04 Focal for Node 16.x simply editing the address to be HTTP instead of HTTPS worked. And “worked” here means apt-get can finish - I am not trying to update or install nodejs at this time. Obviously one does not want to update node from an insecure URL. Another option is to remove the ppa until the issue is fixed.

Fix your client CA chains

# get latest ca certs
wget -O certs.deb http://ftp.fr.debian.org/debian/pool/main/c/ca-certificates/ca-certificates_20210119_all.deb
dpkg --fsys-tarfile certs.deb | tar -xOf - ./usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt > /usr/local/share/ca-certificates/ISRG_Root_X1.crt

# remove expired one
rm -rf /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt


update-ca-certificates

solution mentioned by @nicolai-petrov-venngage worked for me

curl -s http://deb.nodesource.com/gpgkey/nodesource.gpg.key | sudo apt-key add -
sudo sh -c "echo deb http://deb.nodesource.com/node_14.x focal main > /etc/apt/sources.list.d/nodesource.list"
sudo apt-get update
sudo apt-get install nodejs

I update .ebextentions with

sudo sed -i'' '/Alias: DST Root CA X3/,/No Rejected Uses./d' /usr/share/pki/ca-trust-source/ca-bundle.trust.crt
sudo update-ca-trust

It worked and could execute curl --location https://rpm.nodesource.com/setup_12.x in my Elastic Beanstalk Amazon Linux.

See my earlier comment.

#1266 (comment)

The first apt update will have a non-zero exit status, but the ca-certificates package info will have been updated. You can then install it directly. Then apt update again to update the node packages.

I see, thanks. Your explanation helped me understand. Running apt-get -y update || apt-get install ca-certificates worked for me.

I’m running it on gitlab-ci where I need to also consider masking command failure.

the ca-certificates upgrade on ubuntu work-around is removing the X3 cert by blacklisting according to the changelog of ubuntu’s ca-certificates. Theoretically manually removing the expired DST Root CA X3 from /etc/ssl/certs then running update-ca-certificates should be the same thing.

This was causing by BitBucket pipelines to fail and the following changes seem to have fixed it:

Original steps: - curl -sL https://deb.nodesource.com/setup_12.x | bash - - apt-get install -y nodejs

New Steps: - apt-get update - apt-get install -y ca-certificates libgnutls30 - echo ‘-k’ > ~/.curlrc - curl -sL https://deb.nodesource.com/setup_12.x | bash - - apt-get install -y nodejs

That’s work for me . Thank you so much.

getting buster not supported upon installing any NodeSource repo

Same issue here, I was able to fix a similar problem on my own server with the following command:

sudo certbot certonly --nginx -d [domain] --dry-run --preferred-chain=“ISRG Root X1”

That was from here: https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/283

Closing this, should be fixed now.

setting curl to operate unsequre as mentiond by @rogerd330 “solves” the issue temporarily - might have been mentioned already, if that the case, then I’m sorry 😉

echo '-k' > ~/.curlrc

We are aware of the situation and are actively working to fix it, thank you for your patience.

any update on the fix???

Slightly confused, so given that https://deb.nodesource.com/setup_16.x works great in a browser, the certificate seem up to date, so basically the problem lies in dated ca-certificates. For some of us installing the latest version solves the issue, while others have limited success due to varying distributions. So if i get this right ca-certificates needs to be updated - rather than fixed by nodesource. Possibly nodesource could use some other certificate. I’m kindly monitoring the progress here. Keep up the good work!

https://aws.amazon.com/premiumsupport/knowledge-center/ec2-expired-certificate/

This seems to work for me with Amazon Linux 2 (Beanstalk)

I hit this issue today because the app I was working on uses Debian Jessie.

The root CA that letsencrypt used expired on the 30th and the new certificate uses an optional extension to present the new root and the old root certificate. Unfortunately the version of libssl that comes with jessie has a bug which only validates the first presented CA chain. Since the old root cert has expired, the ssl connection fails with an invalid certificate / expired error.

The fix for me was to remove the old root certificate from my CA store and try again:

sed -i '/^mozilla\/DST_Root_CA_X3/s/^/!/' /etc/ca-certificates.conf && update-ca-certificates -f

Credit to https://serverfault.com/questions/1079199/client-on-debian-9-erroneously-reports-expired-certificate-for-letsencrypt-issue for detailing the issue, and the workaround as well.

same issue

solution from danielmoralesp

worked for me on Ubuntu 20.04.3 LTS

A workaround is to use http instead of https but this is not ideal. I hope there is a permanent fix soon 😃

For debian 9 based docker images the following seems to be a minimal workaround to solve a problem: apt update && apt install libssl1.0.2 libgnutls30

After trying this, I found out for me on debian stretch, updating libssl1.0.2 was all that was needed:

apt-get update && apt-get install libssl1.0.2

Hi, the actual issue (when I looked) was that the server(s) are setup with an incomplete certificate chain - I did try to flag this earlier: https://twitter.com/webprofusion/status/1443745049108303873?s=19

In the web server SSL/TLS configuration you specify a cert and the certs private key, but you should also specify a chain of intermediates (or a ‘full chain’), otherwise clients will guess them, and in the case of Let’s Encrypt that leads to clients trying to use the expired R3 path.

After hours of debugging, we have finally managed to fix this by adding these commands at the proper place in dockerfile

RUN apt update RUN apt install libgnutls30 RUN apt install ca-certificates

I updated my nodejs install command and it work well (for now) eb amazon linux 1

command: 'sudo sed -i"" "/Alias: DST Root CA X3/,/No Rejected Uses./d" /usr/share/pki/ca-trust-source/ca-bundle.trust.crt && sudo update-ca-trust && curl --silent --location https://rpm.nodesource.com/setup_12.x | sudo bash - && sudo yum install -y nodejs'

I’m working through this right now, but you have to set up a .curlrc to set the -k flag on all curl calls because the script that ends up running also ends up making a curl call to the nodesource domain

I know it’s not a safe solution (nor adviced) but we’re arising this issue in several Dockerfiles used only to compile some assets in a CI/CD process so we needed a workaround there…

My solution is to disable the certificate check for both curl and apt (script does an apk-add):

echo "insecure" > $HOME/.curlrc # Insecure (-k) for all curls echo "Acquire::https::Verify-Peer false;" >> /etc/apt/apt.conf.d/80ssl-exceptions # Disable apk CA check echo "Acquire::https::Verify-Host false;" >> /etc/apt/apt.conf.d/80ssl-exceptions # Disable apk CA check

With that,it works. Don’t forget to enable it again after installing node & npm:

rm -f $HOME/.curlrc rm -f /etc/apt/apt.conf.d/80ssl-exceptions

Again it’s not a safe solution but it works.

We’ve also checked that this CA certificate problem only happens with debian versions lower than 9 🤔

The following worked for me -

1. curl -sL http://deb.nodesource.com/setup_16.x -o nodesource_setup.sh
2. edit nodesource_setup.sh and replace all https:// with http://
3. chmod 755 nodesource_setup.sh
4. run this script (./nodesource_setup.sh) and let it fail for once so that nodesource.list gets updated with new source url
5. now edit - /etc/apt/sources.list.d/nodesource.list
6. replace [signed-by=…blah…blah] with [trusted=yes]
7. also replace https:// with http:// too in nodesource.list
8. save the nodesource.list and now run ./nodesource_setup.sh
9. after you see the script ran successfully, run this -> apt-get install -y nodejs (add sudo if needed)

None of the above workarounds are working for ubuntu 20.04:

$ apt show ca-certificates
Package: ca-certificates
Version: 20210119~20.04.2

ls: cannot access '/etc/ssl/certs/2e5ac55d.0': No such file or director
ls: cannot access '/etc/ssl/certs/12d55845.0': No such file or directory
ls: cannot access '/etc/ssl/certs/DST_Root_CA_X3.pem': No such file or directory

Still get:

Err:13 https://deb.nodesource.com/node_12.x focal Release               
  Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate.  Could not handshake: Error in the certificate verification. [IP: 23.6.112.24 443]

Remove the Node source from the apt sources.list (either sources.list itself or sources.list.d), then run apt update, then apt upgrade, then once that is all done, put the node source back into apt again and everything should be good to go.

That’s how I managed to eventually fix it.

Basically follow this comment here: https://github.com/nodesource/distributions/issues/1266#issuecomment-931620638

None of the above workarounds are working for ubuntu 20.04:

$ apt show ca-certificates
Package: ca-certificates
Version: 20210119~20.04.2

$ apt show libgnutls30 
Package: libgnutls30
Version: 3.6.13-2ubuntu1.6

ls: cannot access '/etc/ssl/certs/2e5ac55d.0': No such file or director
ls: cannot access '/etc/ssl/certs/12d55845.0': No such file or directory
ls: cannot access '/etc/ssl/certs/DST_Root_CA_X3.pem': No such file or directory

Still get:

Err:13 https://deb.nodesource.com/node_12.x focal Release               
  Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate.  Could not handshake: Error in the certificate verification. [IP: 23.6.112.24 443]

And no, the problem is not solved by disabling nodesource temporarily in the sources.list … As seen from above update and upgrade are working

Slightly confused, so given that https://deb.nodesource.com/setup_16.x works great in a browser, the certificate seem up to date, so basically the problem lies in dated ca-certificates. For some of us installing the latest version solves the issue, while others have limited success due to varying distributions. So if i get this right ca-certificates needs to be updated - rather than fixed by nodesource. Possibly nodesource could use some other certificate. I’m kindly monitoring the progress here. Keep up the good work!

@AleksandarFilipov I don’t fully understand it either, but it seems like a browser will locate the new root certificates, but the Linux tools will opt for the recently expired ones? I wish I could explain it better, but this is not my area of expertise.

You can use the openssl CLI to verify if a website is still using the old certificates:

openssl s_client -connect deb.nodesource.com:443 -servername deb.nodesource.com

=>

CONNECTED(00000007)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
 0 s:/CN=nodesource.com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

For everyone with Vagrant you can vagrant up until the error appears, vagrant ssh and then sudo apt install ca-certificates followed by sudo apt-get updates. Exit and reload your box with --provision.

If still not working check the issue on the laravel/homestead repo, hope it helps.

For Debian buster, updating the libgnutls30 package appears to fix the certificate verification.

apt-get update; apt-get install libgnutls30

@dgarbus not sure how you figured this out but it worked for me 🙏

Just had the same issue when trying to sudo apt update

Any update on this? - this broke all our deploys on Ubuntu 16, Ubuntu 18, Ubuntu 20 and Raspbian 😦

apt update keeps giving me this same error, tried all solutions, have not been able to fix the issue.

I have Ubuntu 20.04 running on WSL2 and none of the commands above worked for me 🤔🙁

this solved our problem on debian stretch:

# 1. Check if ISRG Root X1 already self-signed
openssl x509 -noout -text -in /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt | grep Issuer | grep "CN = ISRG Root X1"
# 2. Set DST Root CA X3 to be removed
sed -i -e "s|^mozilla/DST_Root_CA_X3.crt|\!mozilla/DST_Root_CA_X3.crt|g" /etc/ca-certificates.conf
# 3. Remove it
rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
# 4. Regenerate the combined ca-certificates.pem
update-ca-certificates

If you use AWS EC2 or AWS Elastic Beanstalk, this article is useful for this issue. https://aws.amazon.com/premiumsupport/knowledge-center/ec2-expired-certificate/

Using Debian as root. This particular comment saved my pipeline:

apt-get install openssl ca-certificates

rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
update-ca-certificates

curl -fsSL https://deb.nodesource.com/setup_14.x | bash - # No longer throws an error.
apt-get install -y nodejs

This worked for us and is less invasive as other suggestions. Thanks @german-e-mas @igsu Any update on a permanent fix for this? Thanks in advance.

I was using Debian Jessie based image. Our solution was:

sed -i 's~^mozilla/DST_Root_CA_X3.crt$~!mozilla/DST_Root_CA_X3.crt~g' /etc/ca-certificates.conf && \
 update-ca-certificates

The libgnutls30 is not a guaranteed fix. Still getting intermittent failures about the SSL Cert not being there/valid and NodeJS 14 cannot be installed because of it.

Having the same issue here, but none of the fixes (Without going to the extremes) have worked.

apt update

Hit:1 http://mirror.realcompute.io/debian buster InRelease
Hit:2 http://security.debian.org buster/updates InRelease
Ign:3 https://deb.nodesource.com/node_15.x buster InRelease
Hit:4 http://mirror.realcompute.io/debian buster-updates InRelease
Err:5 https://deb.nodesource.com/node_15.x buster Release
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 121.79.127.16 443]
Ign:6 http://rpms.litespeedtech.com/debian buster InRelease
Hit:7 http://rpms.litespeedtech.com/debian buster Release
Reading package lists... Done
E: The repository 'https://deb.nodesource.com/node_15.x buster Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

If I then do an apt install libgnutls30 it comes back with

apt install libgnutls30

Reading package lists... Done
Building dependency tree
Reading state information... Done
libgnutls30 is already the newest version (3.6.7-4+deb10u7).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

If I do an apt install ca-certificates it comes back with

apt install ca-certificates

Reading package lists... Done
Building dependency tree
Reading state information... Done
ca-certificates is already the newest version (20200601~deb10u2).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

I’ve also tried the removal of the bad certificates then forcing a refresh to no avail.

This is on Debian Buster.

@dominics thank you, that was really helpful, finally got ours working again. we are on elastic beanstalk, ruby 2.6 on amazon linux 1 - I used eb ssh [server] to get on the server and then sudo touch /etc/pki/ca-trust/source/blacklist/DST_Root_CA_X3.pem sudo vim /etc/pki/ca-trust/source/blacklist/DST_Root_CA_X3.pem and then copy and pasted in the pem key, saved and then ran the sudo update-ca-trust. My deployments are not set to immutable thankfully, so redeploying app code didn’t wipe this and it all worked.

I’m assuming if my app runs into a problem and needs to scale or rebuild I’m going to lose this and the site will go down again. Hopefully there is a real fix in the works coming soon! Or someone brilliant will figure out an ebextension for this.

d10sfan has the right server-side fix - also certbot HAS to be newer than 0.12 or a bug may cause the older chain to keep being used.

sudo certbot … --preferred-chain=“ISRG Root X1”

Clients don’t need to do anything if server admins get a new letsencrypt cert intermediate chain. The full chain should only contain your server cert followed by R3 which says Issuer is X1. X1 should have issuer of X1 (real root), not X3 otherwise that’s old.

Debugging from openssl s_client -connect deb.nodesource.com:443 - this is wrong:

Certificate chain
 0 s:CN = nodesource.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

It should look like this:

Certificate chain
 0 s:CN = YOURDOMAIN
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

@Ranarxhag That error is from the script’s attempt to ping NodeSource to see if a file for your system exists. Since it does so over HTTPS, which fails, it interprets that failure as the system being unsupported. Even if you change that check to be HTTP instead you’ll just get a broken repo put into yum that can’t download Node anyway AFAIK.