7

Running sudo apt-get update on my AWS EC2 Ubuntu 18.04.01 LTS instance fails because my Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown when trying to access the deb.nodesource.com/node_10.x bionic Release

Here is the result after running sudo apt-get update

Hit:1 http://us-east-1.ec2.archive.ubuntu.com/ubuntu bionic InRelease
Get:2 http://us-east-1.ec2.archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Ign:3 https://deb.nodesource.com/node_10.x bionic InRelease
Get:4 http://us-east-1.ec2.archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Err:5 https://deb.nodesource.com/node_10.x bionic Release
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: XX.XXX.XX.XX 443]
Get:6 http://security.ubuntu.com/ubuntu bionic-security InRelease [83.2 kB]
Reading package lists... Done
W: https://deb.nodesource.com/node_10.x/dists/bionic/InRelease: No system certificates available. Try installing ca-certificates.
W: https://deb.nodesource.com/node_10.x/dists/bionic/Release: No system certificates available. Try installing ca-certificates.
E: The repository 'https://deb.nodesource.com/node_10.x bionic 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.

It seems like my current installation of Node.js is causing the problem.

I've tried installing and updating ca-certificates in etc/ssl/certs, however, this did not help. I'm not exactly sure how to proceed from here to resolve this issue.

I'm not looking for a quick workaround that would compromise the security of the server.

Thanks in advance!

7

I experienced this error trying to add the keys for mongodb-org 4.0 to a docker container running Ubuntu 18.04. There was a problem with the certificates installed in this base image. I managed to fix it by install ca-certificates:

sudo apt install ca-certificates
| improve this answer | |
  • 1
    Thanks - this actually solved the problem without bypassing security. – carusot42 Mar 27 at 19:42
6

You can add [trusted=yes] in the sources.list. For example:

deb [trusted=yes] http://ppa.launchpad.net/repo_name/pkg/ubuntu vivid main
deb-src [trusted=yes] http://ppa.launchpad.net/repo_name/pkg/ubuntu vivid main
| improve this answer | |
  • 1
    Hi Mike. I'm still seeing the same error after updating both /etc/apt/sources.list and /etc/apt/sources.list.d/nodesource.list with [trusted=yes] as shown above. – Joe Nov 23 '18 at 17:01
  • sorry for the newbie question, but where is sources list, how do I add trusted=yes, and what does "vivid" mean in this context? – schlingel Dec 12 '19 at 8:15
  • If you are VPNing through somewhere that uses ZScaler or something alike then you may hit this problem too. In my case I had only to turn off the vpn and the update went flawless. – Leo May 8 at 8:49
2

Make sure your date and time are set correctly.

| improve this answer | |
0

What caused the problem

I was originally trying to install Node.js on Ubuntu 18.04.01 LTS via PPA and curl via:

curl -sL https://deb.nodesource.com/setup_10.x -o nodesource_setup.sh

However, running this command generated a nodesource.list file in etc/apt/sources.list.d/ with the following contents:

deb https://deb.nodesource.com/node_10.x xenial main
deb-src https://deb.nodesource.com/node_10.x xenial main

So when running sudo apt update these sources could not be trusted via SSL handshake which caused to the update to fail.

How I fixed it

  1. Navigated to /etc/apt/nodesource.list.d
  2. Removed nodesource.list file from the system with

    sudo rm nodesource.list

  3. Purged the system of any current Node.js installation with

    sudo apt-get purge nodejs

    sudo apt-get autoremove

  4. Installed the Distro-Stable Version of Node.js for Ubuntu with:

    sudo apt update

    sudo apt install nodejs

    sudo apt install npm

| improve this answer | |
  • "So when running ... these sources could not be trusted via SSL handshake": Why could they not be trusted? – BlenderBender Apr 20 '19 at 13:47
  • @BlenderBender At the time this error happened, I couldn't find the root cause as to why these sources could not be trusted. – Joe May 23 '19 at 14:35
0

You can replace https:// with http:// from setup script using sed.

curl -sL https://deb.nodesource.com/setup_10.x | sed 's|https://|http://|' | sudo -E bash -

This should be used as the last alternative of course.

| improve this answer | |
0

For those still having this issue, here is a solution which I gleaned from the Ubuntu manpages.

The OP's post indicates a certificate verification error:

Err:5 https://deb.nodesource.com/node_10.x bionic Release
Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: XX.XXX.XX.XX 443]

I was having similar issues on a VM which sits behind a corporate proxy. The proxy acts as a man-in-the-middle, decrypting and re-encrypting traffic as it flows through the proxy. Even though I had the trusted certificate installed on my VM for the proxy, this error was still happening, caused by an invalid OCSP response. To fix it, I ran this command:

touch /etc/apt/apt.conf.d/99verify-peer.conf \
&& echo >>/etc/apt/apt.conf.d/99verify-peer.conf "Acquire { https::Verify-Peer false }"

This disables apt's OCSP verification, and is not recommended.

I chose a different solution, which may not be available to others. Our company maintains a non-decrypting proxy for use cases like this, so I switched to using it.

| improve this answer | |
0

I have encountered a problem that is similar to yours, with the Ubuntu Server installed in a VM, but the underlying cause should be different. I put out the problem description and the solution in case that someone who encountered the same problem reaches here.

Brief Summary: The similar problem is caused by the network condition of our office. When the problem occurs, I used a bridged network for Internet access. After changing the VM network setting to the normal NAT, the problem is mitigated.

Background: I have installed Ubuntu Server LTS 18.04.3 with VMWare Player. After the installation is completed, I have used the VM for several days, including upgrading the system with sudo apt update|upgrade and install new applications with sudo apt install <appname>.

Problem: After a weekend, I reopen the VM and want to install some new software. So I first try to update the repository information with sudo apt update to see if there are something that is upgradable. However, after executing this command, I get the following results:

gary@ubuntu-vm:~$ sudo apt update
Ign:1 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic InRelease
Ign:2 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-updates InRelease
Ign:3 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-backports InRelease
Ign:4 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-security InRelease
Err:5 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic Release
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 101.6.8.193 443]
Err:6 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-updates Release
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 101.6.8.193 443]
Err:7 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-backports Release
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 101.6.8.193 443]
Err:8 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-security Release
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 101.6.8.193 443]
Reading package lists... Done
E: The repository 'https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic 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.
E: The repository 'https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-updates 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.
E: The repository 'https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-backports 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.
E: The repository 'https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-security 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.

which is similar to the aseked problem(e.g., Ign:3 and Err:5), but not the same.

Solution: I have searched the related topics on Google, and many said that the problem is caused by incorrect configuration of certificates. However, I should never change any certificate configuration after installation of the system. Besides, avoiding certificates authentication should not be a regular routine.

To make sure that I did not change related configurations, I reinstall the system. I found that the installation cannot be completed, with the error log similar to the above one. After finding this, I guess that this problem should be caused by the network connection problem, as in this point there is no configuration made to the system.

Therefore, I checked the configuration of the VM instance, and found that this VM uses a bridged network rather than NAT. So I changed the network setting to NAT, which is usually the default network setting, then everything returns to normal!

After that, I recalled that when I first install the VM, I connect my computer to another computer to share the network (using NAT at the second computer). Later, I have my own network connection and I want the VM direct access to the physical network, so I changed the VM network setting to a bridged network, which then caused the problem (It's simply a network connection problem, because the physical network require authentication for network connection, while the VM does not have the credentials).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.