How to Fix GPG Key Error in Kali Linux?

When using Kali Linux (or any APT-based distribution), you might encounter a GPG key error during apt update that prevents the system from refreshing package lists. This error indicates that APT cannot verify a repository due to a missing or invalid GPG key. In Kali’s context, a common example is an error like “NO_PUBKEY ED65462EC8D5E4C5”, which means APT doesn’t have the public key with ID ED65462EC8D5E4C5 needed to validate the Kali repository. In this article, we’ll explain why these errors occur, how APT uses GPG keys to secure packages, and provide step-by-step solutions (both the old apt-key method and the modern gpg method) to fix the issue. We’ll also include a bash script to automate the fix, show how to verify keys before importing, and offer tips to avoid future problems. Finally, we discuss how similar GPG key errors affect other Debian-based systems like Ubuntu and Debian, with links to official documentation.

Understanding APT GPG Key Errors

What is a GPG key error? In APT-based systems, all package repositories are signed with GPG (GNU Privacy Guard) keys. APT uses the public keys to verify that the metadata (Release files) and packages from a repository are authentic and have not been tampered with. If APT cannot find a required public key in its keyring, it will refuse to trust the repository and throw an error. This is the GPG key error — essentially APT saying “I can’t verify this source because I don’t have the key.” Such errors are crucial security safeguards: without the correct key, APT treats the repository as untrusted.

Why does it happen in Kali Linux? There are a few common reasons:

How APT uses GPG keys: APT’s secure package management (often called APT Secure) relies on GPG signatures. When you run apt update, APT fetches the InRelease file (or a Release file and its corresponding Release.gpg signature) from each configured repository. The InRelease file contains checksums for the repository’s package lists and is signed with the repository’s private GPG key (blog.cloudflare.com). APT then tries to verify that signature using the corresponding public key on your system. If the public key is present and the signature is valid, APT knows the repository metadata is authentic and will proceed to use the package lists. If the key is missing or the signature doesn’t match, APT will raise an error and ignore that repository to protect you from potential man-in-the-middle attacks or tampered packages.

In the above output, ED65462EC8D5E4C5 is the key ID of the missing public key. Key IDs are the last 16 characters of a key’s fingerprint (sometimes displayed in two chunks; older apt versions might show a shorter 8-character ID). This particular ID corresponds to Kali’s new archive signing key introduced in 2025. The error “NO_PUBKEY <KEYID>” literally means “No public key with this ID is present.” Until we add that key, APT will distrust the Kali repository, issuing warnings like “The following signatures couldn't be verified because the public key is not available” and “The repository is not updated and the previous index files will be used”.

Why Kali’s Signing Key Changed (2025 Key Rotation)?

Kali Linux users in early 2025 encountered widespread GPG key errors. Offensive Security announced that they lost access to their old repository signing key (ID ED444FF07D8D0BF6) and rolled out a new key (ID ED65462EC8D5E4C5). The new key was signed by Kali developers and published on keyservers, but anyone running apt update on an older Kali installation started seeing the “Missing key 827C8569F2518CC677FECA1AED65462EC8D5E4C5” error. Essentially, Kali’s repository was now signed with a new private key, and systems needed the corresponding new public key.

Offensive Security apologized and provided a one-line fix: downloading and installing an updated keyring package or key file. We’ll detail this fix below. This scenario is a prime example of why GPG key errors occur – when the signing key for a repo changes (even for legitimate reasons), users must update the trusted keys on their systems.

Summary: A GPG key error in Kali means APT cannot find the needed key to verify Kali’s repo. The solution is to add the correct public key to APT’s keyring. There are two main methods to do this:

Next, we’ll walk through both methods step-by-step, including how to validate the key before adding it. After that, you’ll find a convenient bash script to automate the fix.

Method 1: Fixing the Error with apt-key (Deprecated Method)

About apt-key: apt-key is a command-line utility to manage APT’s keyring (historically stored in /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/). In the past, the common way to fix missing key errors was to use apt-key to add the key. However, as of Debian 11 (Bullseye) and Kali/Ubuntu 2022+, apt-key is deprecated and will be removed in the near future. You may still use it on current systems, but you’ll get a warning like “Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead.” Despite deprecation, we show this method for completeness, since many forum solutions and older docs use it.

Step 1 – Obtain the key ID: From the error message, note the 16-character key ID (for example, ED65462EC8D5E4C5). This is the identifier of the missing public key. (For Kali’s official key, the full fingerprint is 827C8569F2518CC677FECA1AED65462EC8D5E4C5 , but we can use the shorter ID.)

Step 2 – Add the key with apt-key: You have a couple of options:

Option A: Use a keyserver – The new Kali key is available on the Ubuntu keyserver. You can fetch and add it in one command:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ED65462EC8D5E4C5

wget -q -O - https://archive.kali.org/archive-key.asc | sudo apt-key add -

This downloads the key and pipes it directly into apt-key add. The apt-key add - command reads the key from stdin and adds it to the trusted keyringopensource.com. (You can also use curl in place of wget similarly).

After running one of the above, you should see a confirmation that the key was added (or no output at all if apt-key is quiet). You can verify by listing keys:

sudo apt-key list

This will show the newly added Kali key in the keyring (look for a UID like “Kali Linux Archive Automatic Signing Key”)

Step 3 – Update APT: Now re-run the package update:

sudo apt update

It should proceed without the earlier error. The Kali repository will be considered trusted, and you won’t see the NO_PUBKEY message. Packages from that repo can now be downloaded and authenticated normally.

Deprecated Tool Warning: Going forward, avoid using apt-key for new keys. The Debian and Ubuntu developers recommend switching to the new key management approach (described next) because apt-key adds keys globally, which is a security concern.

The next method is the recommended way to add repository keys in modern systems.

Method 2: Fixing the Error with gpg (Modern Method)

The modern approach to handling repository GPG keys is to avoid apt-key and instead use GnuPG directly or place key files into APT’s keyrings directory. This gives finer control (like limiting a key to a specific repository using the signed-by option) and avoids the “global trust” problem of apt-key. We’ll cover two ways to do this:

Both achieve the same result: the missing public key gets added to a keyring file under /etc/apt so that APT can use it.

Method 2A: Installing the Official Keyring File

Kali Linux distributes an official keyring package (kali-archive-keyring) which contains the GPG keys for its repositories. Since our goal is to trust Kali’s new signing key, we can simply install the updated keyring. However, when apt update itself is failing, you might not be able to install the package via APT. Instead, we’ll download the keyring file directly:

sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg

This one-liner, recommended by OffSec, fetches the binary keyring (.gpg format) and saves it to /usr/share/keyrings/. Kali’s APT repository configuration is set to look for its key in this location by default (the Kali sources list uses the signed-by option pointing to this file, in newer releases). By placing the new keyring file here, you update the keys that APT will use for Kali’s repo.

Security note: We’re downloading over HTTPS from the official Kali domain, which ensures authenticity. For extra peace of mind, OffSec also published a checksum to verify the download. For example, the SHA-1 of the April 2025 keyring file was 603374c107a90a69d983dbcb4d31e0d6eedfc325. You can run sha1sum /usr/share/keyrings/kali-archive-keyring.gpg and compare it to the official hash. This step is optional but recommended to ensure the file wasn’t corrupted or altered.

2. Inspect the keyring (optional): We can peek inside the downloaded keyring to see what keys it contains. Use GPG in read-only mode:

gpg --no-default-keyring --keyring /usr/share/keyrings/kali-archive-keyring.gpg -k

This lists keys in the specified keyring. You should see two keys: the old Kali key (RSA4096 from 2012, ID ending D8D0BF6) and the new key (RSA4096 from 2025, ID ending E4C5). The presence of the new key ED65462EC8D5E4C5 confirms the file is updated. The output will show the key fingerprint and the UID (which should read something like “Kali Linux Archive Automatic Signing Key (2025) devel@kali.org”).

3. Update APT: With the key in place, run:

sudo apt update

The update should now succeed without any GPG errors. APT will find the new key in /usr/share/keyrings/kali-archive-keyring.gpg and use it to verify the Kali InRelease file, so you’ll see normal package-fetch output. Your system is “rolling” again!

Method 2B: Using GPG and Keyservers to Add the Key

Alternatively, instead of downloading a key file, you can use GPG commands to fetch and install the key. This is essentially what apt-key did behind the scenes, but we’ll do it manually in a more controlled way:

1. Install gnupg (if not already installed): Most Kali installations include GnuPG by default. But if you’re in a minimal environment that lacks it, you may need to install it. (If apt is non-functional due to the key error, you could temporarily download a gnupg .deb from Debian archives and install via dpkg, or skip to using the key file method above.) On a normal Kali system, you can proceed directly.

2. Fetch the key from a keyserver: Use GPG’s receive option to get the key by ID:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys ED65462EC8D5E4C5

This will retrieve the public key from Ubuntu’s keyserver (using HKPS for an encrypted connection) and add it to your personal GPG keyring (~/.gnupg). Once fetched, you should see a message that the key was imported, along with its fingerprint and UID.

3. Export the key and install to APT: Now we need to transfer the key from GnuPG’s keyring to APT’s keyring:

gpg --export --armor ED65462EC8D5E4C5 | sudo tee /etc/apt/trusted.gpg.d/kali-2025.asc > /dev/null

Let’s break down this command:

After this, the key is effectively installed for APT. Keys in /etc/apt/trusted.gpg.d/*.asc or .gpg are automatically loaded by apt. We chose a descriptive filename “kali-2025.asc” – you can name it anything, but make sure to use the correct extension (.asc for armored keys or .gpg for binary).

4. Update APT: Run sudo apt update again. It should succeed now, as APT will find the new Kali key from the file we added. The warnings should be gone.

Validating the key (before or after import): One advantage of manually handling keys is you can verify them. For instance, after step 2, you can run:

gpg --fingerprint ED65462EC8D5E4C5

This will display the key’s full fingerprint and trust info in your personal keyring. You can check that the fingerprint matches the one published by Kali (for example, OffSec shared that the new key’s fingerprint begins with 827C 8569 F251 8CC6 77FE CA1A ... and ends in ... ED65 462E C8D5 E4C5). Additionally, the key’s UID should clearly identify it as the Kali Archive Automatic Signing Key. Verifying these details ensures you fetched the correct key and not an impersonator.

Finally, note that on newer Debian/Ubuntu, a more secure practice is to tie keys to specific repos using the signed-by option in the sources list, and to store those keys in /etc/apt/keyrings/ (a dedicated directory) rather than the global trusted.gpg.d. Kali’s default sources already do this by referencing the key in /usr/share/keyrings/. For most users, however, simply adding the key as shown is sufficient to fix the error.

Automating the Fix with a Bash Script

For convenience, here is a bash script that automates the above process for Kali Linux. This script downloads the Kali Linux repository key (if missing) and installs it, with basic safety checks. It uses the official key file method and verifies the key’s fingerprint before adding it.

#!/usr/bin/env bash
# fix-kali-key.sh – Script to fix missing Kali Linux GPG signing key error.
set -e

KEYFILE="/usr/share/keyrings/kali-archive-keyring.gpg"
KEYURL="https://archive.kali.org/archive-keyring.gpg"
NEEDED_FPR="ED65462EC8D5E4C5"  # Last 16 hex of expected fingerprint (2025 key)

# Require root privileges
if [[ $EUID -ne 0 ]]; then
  echo "[-] This script must be run as root (use sudo)." >&2
  exit 1
fi

echo "[*] Downloading Kali keyring from $KEYURL ..."
TEMP=$(mktemp)  # temporary file
curl -fsSL "$KEYURL" -o "$TEMP"
if [[ $? -ne 0 ]]; then
  echo "[!] Error: Failed to download key file. Check network or URL." >&2
  exit 1
fi

# (Optional) Verify checksum - uncomment and set expected checksum if known
# echo "[*] Verifying file checksum..."
# echo "EXPECTED_SHA256 = <paste_expected_hash_here>"
# sha256sum "$TEMP"

echo "[*] Inspecting downloaded key contents..."
gpg --no-default-keyring --keyring "$TEMP" -k || {
  echo "[!] GPG is not installed or failed to read key. Aborting." >&2
  exit 1
}

# Extract the key fingerprint and check it contains the expected ID
FPR=$(gpg --no-default-keyring --keyring "$TEMP" --with-colons -k 2>/dev/null | grep '^fpr' | head -n1 | cut -d: -f10)
if [[ -n "$NEEDED_FPR" && "$FPR" != *"$NEEDED_FPR" ]]; then
  echo "[!] Warning: The key fingerprint ($FPR) does not contain the expected ID $NEEDED_FPR." >&2
  echo "    The key file may not be the expected one. Aborting to be safe." >&2
  exit 1
fi

echo "[*] Installing key to $KEYFILE ..."
install -o root -g root -m 0644 "$TEMP" "$KEYFILE"
rm -f "$TEMP"

echo "[+] Key installed. Updating package lists..."
apt update

echo "[+] Done. If you saw no errors above, the GPG key issue is resolved."

How This Script Works?

It downloads the archive-keyring.gpg to a temporary file, then uses GPG (with --no-default-keyring) to list the key and grab its fingerprint. We defined an expected fingerprint suffix (NEEDED_FPR) for the new Kali key (you could update this if Kali changes keys in the future). If the downloaded key’s fingerprint doesn’t match, the script aborts with a warning – this is a safety check to ensure we’re installing the correct key. If it matches or if no expected fingerprint is set, the script proceeds to install the key file to /usr/share/keyrings/kali-archive-keyring.gpg (the standard location). Then it runs apt update.

The script uses set -e to stop on errors, and it cleans up the temp file. It also requires you run it as root (or via sudo). By design, it doesn’t use apt-key at all, and it ensures the key file permissions are correct (owner root, mode 0644). This approach is secure and aligns with official recommendations (managing keys by dropping files into the keyrings directory rather than using the deprecated apt-key).

You can save this script as, give it execute permission (chmod +x ), and run it with sudo ./. After it completes, the Kali repo key should be properly installed and apt update should run without GPG errors.

Tips for Maintaining APT Keys and Avoiding Future Issues

deb [signed-by=/usr/share/keyrings/kali-archive-keyring.gpg] http://http.kali.org/kali kali-rolling main contrib non-free

By following these tips, you can minimize the chances of encountering GPG key errors and quickly resolve them when you do.

GPG Key Errors in Other Debian-Based Systems (Ubuntu, Debian, etc.)

The issue of missing GPG keys is not unique to Kali – it can happen on Ubuntu, Linux Mint, Debian, or any APT-based distro. The underlying mechanism is the same: if APT doesn’t have the right public key for a repository, it will refuse to trust the repo. Here’s how it commonly occurs elsewhere and how to handle it:

1. Ubuntu PPAs and third-party repos: When you add a Personal Package Archive (PPA) on Ubuntu (e.g., via add-apt-repository), the system should automatically fetch and install the key. If this fails (or if you add a repo manually in sources.list), you might see a similar NO_PUBKEY error on apt update. The fix is to add the key – on older Ubuntu guides this was done with apt-key, but newer guidance suggests using gpg or placing the key in /etc/apt/trusted.gpg.d/ or /etc/apt/keyrings/. Ubuntu’s community documentation on SecureApt and repository keys is a helpful reference. (In fact, Ubuntu’s wiki defers to Debian’s SecureApt documentation, since the process is identical.)

2. Debian stable key rotations: Debian periodically changes its archive signing keys (for example, new Stable releases come with new keys, and old ones expire). If you’re tracking an old release or haven’t updated the debian-archive-keyring package, you may get signature errors. The solution is to install the latest keyring package from the official Debian repos (which contains the new keys). There is an official Debian wiki page called SecureApt that explains how to find and add missing keys and discusses key expiry. Debian’s aptitude/apt will usually prompt you to update keyring packages during a dist-upgrade to avoid this, but manual intervention is sometimes needed if using Debian’s ports or archives.

3. Linux Mint and others: Mint (based on Ubuntu) and other derivatives also use APT keys. The same approaches apply. For instance, Linux Mint’s documentation has begun advising to put keys in trusted.gpg.d and not use apt-key in newer releases (as they inherit Ubuntu’s changes).

In summary, GPG key errors are a protective feature of APT. Whether on Kali, Ubuntu, or Debian, the resolution is to obtain and install the correct public key for the repository. The specifics might differ (downloading a key file, installing a keyring package, or running a gpg command), but the principle is the same. Using the official documentation of your distribution is the best way to get the exact steps and key fingerprints to trust. With the guidance in this article, you should be well-equipped to fix GPG key errors in Kali Linux and beyond, keeping your system’s package management secure and functional.

Thanks for reading this tutorial post. Visit our website, thesecmaster.com, and our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium & Instagram, and subscribe to receive updates like this.

You may also like these articles: