We've researched the causes and solutions so you don't have to

 

It usually takes ~10 minutes to fix this error.

Symptoms and their solutions ahead. When you see symptoms that don't fit yours — just ignore them and go to the next section.

 

All commands, filenames and locations are for Debian-based distributions. For other operating systems the process is roughly the same, so you will have an idea of what needs to be done.

If you get a "Permission denied" or similar error, add sudo at the beginning of the command.

When troubleshooting, split lines with multiple commands into separate lines. This will make the error output easier to understand. Instead of

[command_1] | [command_2]

do this:

[command_1]
[command_2]

 

 

First do this regardless

Let's see if GPG application is okay. Encrypt any file using the CLI:

gpg --encrypt [file]

And decrypt it:

gpg --decrypt [file]

If it works, GPG is not broken. Skip the rest of this section and go see the next section.

If it doesn't work, update it:

sudo apt install gnupg

Or better yet, upgrade all packages installed on the system, which is almost always a good idea:

sudo apt upgrade

Restart GPG:

sudo systemctl restart gpg

Now try to decrypt the file / verify the signature again:

gpg --encrypt [file]
gpg --decrypt [file]

At this point GPG must function properly.


If the file / signature is in your file manager

If you're trying to

  • decrypt a file,
  • verify its signature, or
  • verify signed message, …

... and it's located in your file system or on external data storage device like USB flash drive, see this section.

File or signature may be corrupt or improperly formatted. Or you may have overlooked that the file isn't really encrypted / the signature is missing.

You can check if your target even has proper OpenPGP packets. This works with any target: encrypted and/or signed files and signed messages (in .txt file). Enter this:

gpg --list-packets [file]

Normal output will look like this:     

                 

If your file is corrupt, improperly formatted, or unencrypted, the output will be:

If it's a signature, check the obvious: visually compare it to another signature that you can successfully verify. You may find, for example, that you did not copy the signature in its entirety.

 

If you download and install software with CLI

 

Intro

If you do something like this:

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

and gpg: no valid OpenPGP data found error happens, your computer can't get the public key for some reason.

 

NB!  apt-key add is an example. Do NOT use it, it's NOT safe. Here's why and what to do instead. man apt-key confirms: 


Let's refresh the keyring:

gpg --refresh-keys

And go to the next section Are you behind proxy or firewall? if this didn't help.

 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Theory bit about how this works

Repository and PPA (Personal Package Archive) maintainers digitally sign the packages they distribute — it's a security measure. Your computer can check their signature. If the signature is okay, then the packages are fine, too: authorized by the package maintainers and not modified by unauthorized party. In order to check the signature your computer have to know repository maintainer's public PGP key. That's why when you command to download and install a package you also command to download repository's public PGP key.

 

Extensive reading list for practice

And “Additional resources” from the end of “Manage keyring files…”:

 ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾ ‾

1. Are you behind proxy or firewall?

 

First of all, ensure that your environment knows about it:

export http_proxy=http://proxy_server_address:port
export https_proxy=https://proxy_server_address:port

Or, if your proxy server requires authentication:

export http_proxy=http://username:password@proxy_server_address:port
export https_proxy=https://username:password@proxy_server_address:port

If it doesn't help, "http" for "https_proxy" instead of "https" might help:

export https_proxy=http://username:password@proxy_server_address:port

This will not survive a reboot, so you should try this search query: "set environment variables permanently [your OS name]".


Try to open your download URL in web browser to check if it's accessible. If it's not, there's a good chance you do have a problem with networking.


If you are behind company / school / college proxy

To monitor and block traffic between their users and the Internet, their server tells your computer, "I am a Certificate Authority. You must trust me when I tell you which SSL certificates to use to encrypt your traffic". By the way, it's basically a real man-in-the-middle attack. You need to add the "attacker's" certificate (cert, for short) to the system's trusted certificate authority (CA) repository. Otherwise you won't be able to connect to anything that requires HTTPS, including package repositories.

To do this, you need to get a .cer or .crt file from your system administrator. Find a folder with all your CA certificates (/usr/local/share/ca-certificates/ for Debian-based OS), create a new folder and put new certificates in it. Make sure the permissions are correct (755 for the folder, 644 for the file) and run "sudo update-ca-certificates".

If the CA certificate is not a problem, check firewall rules and other network restrictions.

Check that DNS settings are configured correctly:

cat /etc/resolv.conf

If the DNS server isn't resolving the hostname correctly, this can cause problems with SSL certificate verification.

[https://linuxize.com/post/chmod-command-in-linux/]
[https://wiki.debian.org/Permissions]
[https://askubuntu.com/questions/645818/how-to-install-certificates-for-command-line]


2. Update CA certificates

Maybe your CA certificates are old (deprecated), broken, or missing. Run

sudo apt install --reinstall ca-certificates

[What is the use/purpose of the ca-certificates package?]
[Ubuntu Manpage]


3. Update all existing packages

sudo apt upgrade

This is a good idea for almost any problem. This will, among other things, update GPG (tool for OpenPGP) and tools used to download packages: wget, curl, etc.


4. Change the download tool

It happens that curl gives an error, but wget does the process correctly and vice versa.

To install these tools, run

sudo apt install curl
sudo apt install wget

 

5. Change the path in the .bashrc file

If gpg: no valid OpenPGP data found is caused by the computer looking for the CA certification in the wrong path, you can change the path in the .bashrc file.

Use the following command to open the .bashrc file executable script file:

nano ~/.bashrc

Once the file opens, add the following command to it:

export CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt

Press Ctrl + O to save the file and Ctrl + X to exit the nano editor.

This command will add the correct path to the file.

This might be helpful:

[Messed-up with ca-certificates/ How to restore back to default]
[How do you add a certificate authority (CA) to Ubuntu?]
[update-ca-certificates (8) - Linux Manuals]

 

6. Disable SSL certificate verification

Only as a temporary workaround for testing purposes. This is highly unsafe in itself, and even more so in the context of GPG. Strangely, this advice has 140 "useful" points on Stack Overflow and very few people warn against it. They also explain the correct use and precautions, so, please, refer to these links.

 

Where to get (more) help

On websites like these:
https://superuser.com/
https://stackoverflow.com/
https://unix.stackexchange.com/
https://ubuntuforums.org/
https://askubuntu.com/