Stuck on a GPG key error during an `apt-get update`? This senior engineer’s guide breaks down the root cause and provides three distinct fixes to get your Linux servers—and your deployment pipeline—back in line.

“I Don’t Know How to Fix This”: A Senior Engineer’s Guide to That Pesky GPG Key Error

I remember it like it was yesterday. 2 AM, a critical hotfix deployment was failing, and the error logs on `prod-app-worker-03` were screaming at me. It wasn’t a code bug. It wasn’t a networking issue. It was a cryptic GPG error during a routine `apt-get update`. A tiny, expired security key on a third-party repository brought our entire deployment pipeline to its knees. That night, I learned that the most frustrating problems aren’t the complex architectural ones, but the simple, opaque ones that block you when you’re most vulnerable. If you’ve hit this wall, trust me, you’re not alone. Let’s get you through it.

First, Let’s Understand the “Why”

Before we dive into the fixes, you need to understand what’s happening. When you run `apt-get update`, you’re not just downloading a list of packages. You’re downloading a list that has been cryptographically signed by the repository’s owner. This signature is your guarantee that the package list (and by extension, the software you’re about to install) is authentic and hasn’t been tampered with by some bad actor.

The system uses GPG (GNU Privacy Guard) keys to verify this signature. The error message you’re seeing, something like this…

W: GPG error: http://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.4 Release: The following signatures were invalid: EXPKEYSIG 2930ADAE8CAF5059 MongoDB 4.4 Release Signing Key <packaging@mongodb.com>
E: The repository 'http://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.4 Release' is not signed.

…is your server’s security system doing its job. It’s telling you, “Hey, I can’t verify the signature for this repo because the key I have (2930ADAE8CAF5059) is expired or invalid. I’m stopping here to protect you.” It’s a feature, not a bug. But it feels like a bug.

The Fixes: From a Band-Aid to a Permanent Solution

I’ve seen engineers try all sorts of things, from blindly adding `–allow-unauthenticated` (please, never do this in production) to just deleting the server and starting over. Let’s walk through the right ways to handle this, from fastest to most robust.

Solution 1: The Quick Fix (The “It’s 2 AM and I Just Need This to Work” Method)

This is the most common fix you’ll find online. It directly targets the expired key and fetches the new one from a public keyserver. It’s fast, effective, and perfect for an emergency.

1. Identify the expired key ID. The error message gives it to you. In our example, it’s 2930ADAE8CAF5059.
2. Fetch the new key. You’ll use `apt-key adv` to grab the updated key from a keyserver.

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 2930ADAE8CAF5059

Once that command succeeds, run `sudo apt-get update` again. The error should be gone. You’re back in business.

Darian’s Take: This is a perfectly valid fix, but I consider it a band-aid. You’re manually managing a key, which can be a pain to automate across a fleet of servers or in a Dockerfile. It works, but it’s not the cleanest long-term solution.

Solution 2: The Permanent Fix (The “Do It Right” Method)

A better, more permanent approach is to manage repository keys the way the maintainers intended: by using their official key files. This method is more declarative and idempotent, which is exactly what we want in our infrastructure-as-code world.

Most modern repositories have moved away from `apt-key` and now provide a `.gpg` or `.asc` file that you download and place in `/etc/apt/trusted.gpg.d/`. This keeps keys organized and tied to their respective repos.

1. Find the official instructions. Go to the documentation for the software you’re trying to install (e.g., “Install MongoDB on Ubuntu”). They will have a specific command for adding their GPG key.
2. Execute the official command. It will look something like this:

# Example for MongoDB
wget -qO - https://www.mongodb.org/static/pgp/server-4.4.asc | sudo apt-key add -

# A more modern and preferred example for Docker
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Notice the second example is better because it doesn’t use the now-deprecated `apt-key add`. It places the key in a specific file under `/usr/share/keyrings`. If you’re setting up a new server or a base image, this is the way to go.

Solution 3: The ‘Nuclear’ Option (When You’ve Made a Mess)

Sometimes, we inherit systems where keys have been added and removed so many times that the keyring is a mess. Maybe you’ve tried the other fixes and something is still conflicting. It’s time to bring out the sledgehammer.

This involves completely removing the repository’s source list and its associated key, then re-adding it from scratch using the official instructions (as in Solution 2).

CRITICAL WARNING: Be extremely careful here. Deleting the wrong files can break your system’s ability to update itself. Double-check your filenames before you hit Enter. This is for the problematic third-party repo, NOT for the base OS repos.

1. Identify the repo’s files. They are usually located in `/etc/apt/sources.list.d/` and `/etc/apt/trusted.gpg.d/`.
2. Delete them. For our MongoDB example:

# DANGER: Verify these filenames match YOUR problematic repo!
sudo rm /etc/apt/sources.list.d/mongodb-org-4.4.list
sudo rm /etc/apt/trusted.gpg.d/mongodb-org-4.4.gpg

3. Re-add the repository. Go back to the official documentation and follow the installation steps from the very beginning, as if you’ve never added it before. This will create clean, new list and key files.
4. Run `sudo apt-get update`. You should have a clean slate.

Choosing Your Path

So, which one should you use? Here’s my cheat sheet for you.

At the end of the day, this error is a rite of passage. It’s frustrating, but it teaches a valuable lesson about the importance of security and verification in our supply chain. Now you not only know how to fix it, but you know why you’re fixing it. Go get that pipeline green.

– Darian Vance

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions