Why Your Update Failed
If you've hit a wall while updating your packages, you're probably staring at a wall of text like this:
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.example.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG 40976EAF437D05B5
W: Failed to fetch http://repo.example.com/debian/dists/stable/InRelease The following signatures were invalid: EXPKEYSIG 40976EAF437D05B5
W: Some index files failed to download. They have been ignored, or old ones used instead.
The Root Cause
Linux distributions rely on GPG (GNU Privacy Guard) keys to sign repository packages. This verification process ensures the code you download hasn't been modified by a third party. Most of these keys have a built-in shelf life, typically expiring every 2 to 5 years to maintain security standards.
The EXPKEYSIG error triggers when your local system holds an outdated public key. It can also happen if a repository maintainer issues a new key but fails to update the metadata correctly. While it's a vital security feature, it can be frustrating when it blocks a critical 2 AM dependency install. Let's get your system back on track.
Solution 1: Refreshing via Keyserver (Legacy Method)
Standard repositories, like those for Ubuntu or Debian, often use a public keyserver. You can pull the latest key version using the 8 or 16-character ID from your error message. In our example, that ID is 40976EAF437D05B5 (which is actually the Ubuntu Archive Master Signing Key).
Run this command, replacing the ID with the one shown in your terminal:
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5
After the terminal confirms the key is updated, try your update again:
sudo apt update
Note: You might see a "deprecated" warning on newer systems. If so, move to Solution 2.
Solution 2: The Modern GPG Method (Ubuntu 22.04+ and Debian 12)
Modern Linux versions are moving away from apt-key. Instead, they store keys in /usr/share/keyrings/ or /etc/apt/trusted.gpg.d/. This is more secure and keeps the global trust store clean.
Follow these steps to export the key manually:
# Receive the key into your local GPG keyring
gpg --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5
# Export it to the trusted directory in a format APT understands
gpg --export 40976EAF437D05B5 | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/renewed-key.gpg
Still seeing errors? Check the specific .list file in /etc/apt/sources.list.d/. Ensure it includes a signed-by flag pointing to your new .gpg file.
Solution 3: Fixing Third-Party Repos (Docker, Google, Node)
Vendors like Google or Docker don't always use the Ubuntu keyservers. They host their own key files. If the steps above fail, you need to download the key directly from the provider.
To fix Google Chrome or Cloud SDK errors:
curl https://dl.google.com/linux/linux_signing_key.pub | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/google.gpg
To fix Docker repository errors:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
Solution 4: Clear and Re-add (The Clean Slate)
Local keyrings can sometimes become corrupted if they contain multiple conflicting versions of the same key. If you're stuck in a loop, try removing the old key entirely before re-adding it.
- Find the key name:
apt-key list - Delete the expired key:
sudo apt-key del 40976EAF437D05B5 - Re-run the import command from Solution 1 or 2.
Verification: Confirming the Fix
Run this sequence to ensure everything is synced:
sudo apt clean
sudo apt update
Success looks like a clean "Reading package lists... Done" message. If you don't see any lines starting with "W:" or "E:" regarding GPG, your signatures are valid and your system is secure.
Proactive Maintenance
Key expiration is a routine part of server maintenance. You can stay ahead of these errors with a few simple habits. First, update your system weekly; updates often include new keyring packages that extend expiration dates.
Second, use official installation scripts from vendors like HashiCorp or NodeSource. These scripts usually include logic to handle keyring rotations automatically. Finally, if you manage multiple servers, monitor your logs for "W:" strings to catch expiring keys before they break your deployment pipelines.