How to Fix GPG Errors on apt Repositories (September 2026)?

If you have ever run sudo apt update on Ubuntu or Debian and watched it fail with the message “the following signatures couldn’t be verified,” you know how frustrating the error feels. I have hit this exact problem more times than I can count, usually right after adding a third-party repository for tools like Docker, Spotify, or Yarn. The error blocks your package list from updating, which means no new software and no security patches until you resolve it.

This guide walks you through fixing GPG signature errors on apt repositories. You will learn what causes the error, how to decode the three main variants (NO_PUBKEY, EXPKEYSIG, and BADSIG), and how to resolve each one using both the legacy apt-key method and the modern keyring approach. By the end, you will have a repeatable workflow for diagnosing and clearing these errors on any Debian-based system you manage in 2026.

What Is GPG Signature Verification in apt and Why Does It Matter?

GPG (GNU Privacy Guard) signature verification is how apt confirms that the packages you install actually came from the maintainer of the repository you added. When a repository maintainer signs their packages with a private key, your system uses the matching public key to verify that signature. If the public key is missing, expired, or corrupted, apt cannot prove the package is genuine, so it refuses to install it.

This system relies on public-key cryptography. The repository owner keeps the private key secret and uses it to sign every package release. You, the user, import the public key into your local keyring. When apt fetches a package, it checks the signature against your stored public key. A valid match means the package is trusted. A mismatch, missing key, or expired key means apt cannot trust the package, and it raises one of the GPG errors we will cover below.

I treat this verification layer as essential. Without it, any attacker who intercepted your connection could swap a real package for a trojaned one, and your system would install it without question. GPG signatures make that attack impractical, which is why Ubuntu, Debian, Linux Mint, Pop!_OS, and every other Debian-derived distribution enforce them by default.

Why You See ‘The Following Signatures Couldn’t Be Verified’ Error?

The message “the following signatures couldn’t be verified” is apt‘s way of telling you that it has packages waiting in a repository, but it cannot prove they came from that repository’s maintainer. In practice, this almost always means one of three things: the public key for the repository is missing from your system, the key has expired, or your stored copy of the key does not match what the repository is using.

I usually see this after adding a new third-party repository without importing its signing key, after upgrading from one Ubuntu release to the next (which can invalidate old keys), or after a maintainer rotates their signing key and forgets to update their docs. Older guides that copy and paste apt-key add commands without updating the keyring path also cause this on fresh installs in 2026.

The error itself is non-destructive. It will not corrupt your system. But it does block apt update from finishing, which means you cannot install or upgrade any packages until you fix the underlying key issue.

Common GPG Error Variants You Will Encounter

The error message you see usually includes a short code that tells you exactly which scenario you are in. Learning to read those three codes saves you a lot of guesswork when triaging.

NO_PUBKEY — this is the most common variant. The full message looks like NO_PUBKEY 6E3C8E5A5B1234567. It means your system does not have the public key for that repository at all. You need to fetch the key from the maintainer’s site or a public keyserver and add it to your keyring.

EXPKEYSIG — this one shows the maintainer’s name and email, like EXPKEYSIG 6E3C8E5A5B1234567 Some Maintainer <[email protected]>. It means the key was present but it has now expired. Most often this happens with software vendors who signed a key years ago and forgot to renew it, or with repository infrastructure keys that the upstream team retired.

BADSIG — this means apt found a key but the signature on the package does not match it. Either the keyring is corrupted, the package was tampered with (rare), or your local cache is stale. A simple apt clean usually clears this up.

Whenever I see a GPG error I copy the full line, including the 10-character key ID. That ID is what every fix command below will rely on.

Fixing NO_PUBKEY Error Step by Step

The NO_PUBKEY error is the one I fix most often, and the workflow below resolves it on Ubuntu, Debian, Linux Mint, Pop!_OS, and Elementary OS. I use this same sequence on every machine I administer.

Step 1: Identify the missing key. Look at the full apt update output and copy the 10-character key ID that follows NO_PUBKEY. For example, in W: GPG error: http://repo.example.com stable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 6E3C8E5A5B1234567, the key ID is 6E3C8E5A5B1234567.

Step 2: Fetch the key from a keyserver. Run this command, replacing the key ID with your own:

sudo gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 6E3C8E5A5B1234567

If you are on Debian, use hkp://keyring.debian.org instead. If the keyserver returns “no data,” try hkp://pgp.mit.edu or hkps://keys.openpgp.org. I keep all three in a sticky note because keyserver availability changes.

Step 3: Export the key into the apt keyring. Take the key you just downloaded and export it to /etc/apt/trusted.gpg.d/ using a descriptive filename:

sudo gpg --export 6E3C8E5A5B1234567 | sudo tee /etc/apt/trusted.gpg.d/repo-example.gpg > /dev/null

Step 4: Update your package lists. Run sudo apt update again. The NO_PUBKEY warning should be gone for that repository. If you have multiple missing keys, repeat steps 2 and 3 for each one before updating.

Fixing EXPKEYSIG Error (Expired Signing Keys)

When the error is EXPKEYSIG, the repository owner needs to issue a fresh signing key, and your system needs to import it. The Yarn package manager repository is famous for this; I have seen it expire on multiple machines over the past few years.

First, try fetching the same key ID from a keyserver. The maintainer often rotates to a new key while keeping the old key ID, so the same gpg --recv-keys command from the NO_PUBKEY section will sometimes work:

sudo gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys KEYID
sudo gpg --export KEYID | sudo tee /etc/apt/trusted.gpg.d/repo-name.gpg > /dev/null
sudo apt update

If that fails, visit the repository’s official documentation page. Look for an updated signing key URL or instructions from the maintainer. For example, the Yarn project publishes their current key on their website. Download it directly with wget or curl and store it in /etc/apt/trusted.gpg.d/:

curl -sSL https://dl.yarnpkg.com/debian/pubkey.gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/yarn.gpg
sudo apt update

Never trust an expired key just to silence the error. Always fetch the current key from the project’s official source. This is one of the rules I never break on production systems.

Fixing BADSIG Error (Invalid Signatures)

The BADSIG error usually means your local apt cache is out of sync with the repository. The fix is almost always straightforward. I run these two commands back to back:

sudo apt clean
sudo apt update

If the error persists, remove the cached package lists for the affected repository. You can find them in /var/lib/apt/lists/. Delete the partial files (those ending in Remov) and the entries for the repository, then update again.

In rare cases BADSIG points to a genuine mismatch between your stored key and what the repository is signing with. Re-import the key using the steps in the NO_PUBKEY section to be sure.

Modern Method: Using /etc/apt/trusted.gpg.d/ Instead of apt-key

If you have followed an older tutorial, you have probably seen commands like sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys KEYID. That command still works, but on modern Debian and Ubuntu systems it prints a warning: Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

That warning is important. apt-key stores every imported key in a single global keyring at /etc/apt/trusted.gpg. That means every repository on your system shares the same trust database, and removing one key risks breaking another. The modern approach gives each repository its own keyring file inside /etc/apt/trusted.gpg.d/, so keys are scoped, easier to audit, and simpler to revoke.

Here is the comparison I keep in mind when helping other admins in 2026.

Legacy approach (apt-key):

wget -qO - https://example.com/key.gpg | sudo apt-key add -

Modern approach (per-repo keyring):

wget -qO - https://example.com/key.gpg | sudo gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/example.gpg > /dev/null

Both methods end up letting apt verify packages, but the modern approach gives you better isolation, easier cleanup, and no deprecation warning. For new repository additions, I always reach for the /etc/apt/trusted.gpg.d/ method first.

Best Practices and Troubleshooting Tips for apt Key Management

Over the years I have settled on a few habits that prevent most GPG errors from recurring. Sharing them here because they save real time during incidents.

Always fetch keys from the source the repository publishes. Do not blindly copy keys from blog posts or Stack Overflow answers. The maintainer’s official site, GitHub releases page, or documentation is the safest source. Third-party keyservers can serve outdated or spoofed keys.

Use verbose output when you are stuck. Run sudo apt-get update -o Debug::Acquire::gpgv=true to see exactly which key apt is trying to use and why it is failing. That one command has saved me hours of trial and error.

List and audit your keyrings regularly. Use ls -l /etc/apt/trusted.gpg.d/ and apt-key list to see which keys are loaded. If you no longer use a repository, delete its keyring file. This keeps your trust surface small and makes future audits faster.

Set sane file permissions. Keyring files in /etc/apt/trusted.gpg.d/ should be owned by root and readable only by root. If permissions are too loose, apt may ignore the key with a confusing warning.

sudo chown root:root /etc/apt/trusted.gpg.d/*.gpg
sudo chmod 644 /etc/apt/trusted.gpg.d/*.gpg

Keep a small backup of your keyring files. I keep an encrypted backup of /etc/apt/trusted.gpg.d/ alongside my dotfiles. When a server crashes or I migrate to a new machine, restoring the directory is faster than re-importing every key from scratch.

Frequently Asked Questions

Conclusion

Fixing the GPG error “the following signatures couldn’t be verified” on apt repositories comes down to three repeatable steps. Identify the error code, fetch or refresh the signing key from an official source, and store it in the right keyring location. Whether you use the legacy apt-key path or the modern /etc/apt/trusted.gpg.d/ approach, the end result is the same: apt trusts your packages again and your system stays secure.

Open a terminal on your affected machine, copy the key ID from the most recent NO_PUBKEY or EXPKEYSIG line, and run the commands above. Within a few minutes the error will be gone and your package lists will update cleanly. If you found this guide helpful, bookmark it for the next time you add a new third-party repository.