Kali "apt update" Fails: Signatures Invalid or NO_PUBKEY Error (2026 Fix)
If sudo apt update on Kali Linux is throwing GPG error: ... The following signatures were invalid or NO_PUBKEY, the fix is almost never about your download being corrupted or your machine being compromised — it's that Kali's own signing key changed and your system's local copy of that key is out of date. Fetch the current keyring with one command, and the error clears. The one-line fix, why it keeps happening, and what to do when the one-liner doesn't work, are all below.
Jake found this out the hard way on a Friday night. He runs a phone shop, and on Saturdays he'd started offering a walk-in "router health check" using a Kali VM on the shop laptop — scan the customer's Wi-Fi, flag anything obviously open, charge a small fee, sell a mesh router if theirs is garbage. He hadn't touched the VM in a few months. He ran apt update to grab the latest Nmap before Saturday's first booking, and it just... refused. Red text, the word "invalid," no explanation he could parse.
He texted a screenshot to Ethan at 9:40pm with the message "did I get hacked." Ethan, who does freelance security consulting on the side and has talked Jake through more than one late-night Kali problem, didn't even need to see the whole error to know what it was — the word "signature" in that specific pattern almost always means the exact same thing, and it's almost never the scary thing it sounds like.
🙋♂️ Jake's Reality Check
"Did someone hack my mirror? Is my download broken? Do I need to wipe the VM and start over the night before a paying appointment?"
No, no, and no. Nothing was tampered with. Kali's signing key changed, your VM's copy is stale, and the fix is one command that takes about ten seconds.
Why apt suddenly stops trusting a repository it trusted last month
Every package Kali serves from its network repository is wrapped inside a file called InRelease, and that file is digitally signed with a GPG key that only the Kali team holds. Before apt will install or update anything, it checks that signature against a copy of the public half of that key stored on your machine, at /usr/share/keyrings/kali-archive-keyring.gpg. If the signature checks out, apt trusts the repository. If it doesn't — because the key on your machine is missing, expired, or simply the wrong one — apt refuses, on purpose. That refusal is the entire point of the system: it's what stops someone from slipping you a tampered package on an open network.
"Think of it like a passport that gets renewed," is how Ethan explained it to Jake over the phone. "The passport office doesn't hack you when your passport expires. They just expect you to go get the new one. Kali's key works the same way — it gets renewed every couple of years, and your machine needs to go get the update. Nobody broke in. You just didn't renew."
The error text you see depends on which verification tool your Kali install uses. Older systems (2024 and earlier images that haven't been refreshed) verify signatures with GPG directly and print NO_PUBKEY followed by a short key ID like ED65462EC8D5E4C5. Current Kali uses a newer verifier called sqv (Sequoia-PGP), and it prints a longer, more specific message: Sub-process /usr/bin/sqv returned an error code (1), error message is: Missing key 827C8569F2518CC677FECA1AED65462EC8D5E4C5, which is needed to verify signature. Both messages point at the same root cause — apt can't find a valid, current copy of Kali's signing key. sqv also rejects signatures based on the older SHA-1 hash algorithm, which is a separate reason an ancient, never-updated install can start failing even without a key change.
The short history behind this exact error
This isn't a one-time glitch — it's a recurring, documented event, and knowing the timeline helps explain why your specific machine is affected and someone else's isn't.
🕐 What changed, and when
- The Kali archive's old signing key was lost in April 2025, which forced a new key onto every installation going forward.
- Kali's documentation states the team extends or replaces this signing key roughly every two to three years by design — so this is not a one-off event, it's a maintenance cycle.
- With the Kali 2026.2 release (June 29, 2026), the repository configuration itself moved to a new file format, changing where the "trust this key" setting lives on a freshly installed system.
- What that means for you: if your Kali install predates any of those changes and hasn't updated its keyring since, apt is comparing an old key against a repository signed with a newer one — and correctly refusing to proceed.
Anyone running an install that's more than a year or two old, or a VM or ISO snapshot that's been sitting untouched, is the exact profile this hits. It also explains why a brand-new Kali install almost never sees this error — it ships with the current key already in place.
Fixing it on current Kali (2026.2 and newer, using kali.sources)
Since the 2026.2 release, a clean Kali install keeps its repository configuration in /etc/apt/sources.list.d/kali.sources, written in a newer, multi-line format (called deb822-style) instead of the older single-line style. That file has a line reading Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg — that path is exactly the file you're about to refresh.
- Confirm which file you're using. Run
ls /etc/apt/sources.list.d/kali.sources. If it exists, you're on the current format and these steps apply directly. - Download the current keyring, overwriting the stale one. Run
sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg. This pulls the exact key file Kali's own repository trusts today and writes it to the path yourkali.sourcesfile already points at — no config editing needed. - Re-run the update.
sudo apt update. The signature check should now pass silently, with no warnings. - Confirm the fingerprint if you want certainty, not just silence.
gpg --show-keys --with-fingerprint /usr/share/keyrings/kali-archive-keyring.gpgshould show827C 8569 F251 8CC6 77FE CA1A ED65 462E C8D5 E4C5. That's the current archive key as documented by Kali.
If you're still on the older, single-line /etc/apt/sources.list format but want to move to the current one, Kali ships a built-in migration command: sudo apt modernize-sources. It rewrites your old file into the new kali.sources format, fills in the Signed-By value automatically, and keeps a backup of the original as a .list.bak file. Run it once you've already fixed the key with the steps above.
Fixing it on older Kali (pre-2026.2, still using sources.list)
These steps are the same underlying fix as above — you're refreshing the same key file — but you're working with the older single-line configuration instead.
- Check your current repository line. Run
grep -v '^#' /etc/apt/sources.list. On a standard install it should readdeb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware. If it looks nothing like that, you've likely picked up a stray or hardcoded mirror line at some point — worth cleaning up while you're in there. - Fetch the current archive keyring the same way.
sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg. - Run the update.
sudo apt update. - Optional but worthwhile: modernize.
sudo apt modernize-sourcesmoves you onto the currentkali.sourcesformat so this exact confusion doesn't repeat next time the format changes again.
✅ Why this is the one to use
Fetching the keyring straight from archive.kali.org and overwriting the same path apt already checks is the shortest possible path back to a working apt update, and it doesn't touch anything else about your system — no reinstall, no re-adding repositories, no third-party keyservers.
When it isn't a missing key at all
Not every "invalid signature" error is the same error. A few variants look nearly identical but point somewhere else:
EXPKEYSIG instead of NO_PUBKEY
This means you already have a key on file, but it's specifically flagged as expired rather than missing. It shows up on installs that are old enough to have the previous key, but haven't run an update since that key's expiry date passed. The fix is identical — refresh the keyring file with the same wget command above.
The system clock is badly wrong
GPG signature checks are time-sensitive: a key or signature can be rejected as "not yet valid" or "expired" if your machine's clock is far off, which happens often on VMs that were cloned, suspended for months, or restored from an old snapshot without network time sync. Run date and compare it to reality before you assume the key itself is the problem.
A captive portal, proxy, or filtered network
Coffee-shop Wi-Fi, corporate proxies, and some VPNs intercept and rewrite HTTP traffic, which can corrupt or replace the InRelease file in transit and produce a genuinely invalid signature — not a stale-key problem at all. If refreshing the keyring doesn't help, try a different network before troubleshooting further.
⚠️ What this actually breaks if you ignore it
Every time this fails, apt falls back to whatever package index it downloaded last — which could be months old on a machine you haven't updated. That means tools you install "successfully" may be outdated, and known security fixes for those tools simply aren't applied. On a penetration-testing distribution, running stale tools isn't just an inconvenience.
Branches and mirrors: the setting most people never check
Kali offers two main branches, and which one you're on changes how often you'll run into key or update surprises like this one at all.
| Branch | Update pace | Best for |
|---|---|---|
| kali-rolling | Continuous, frequent updates | Default choice; newest tools as soon as they land |
| kali-last-snapshot | Point release, updated quarterly | More stability, fewer moving parts between updates |
Switching branches is a one-line edit. On current Kali, running sudo sed -i 's/^Suites: .*/Suites: kali-rolling/' /etc/apt/sources.list.d/kali.sources keeps you on the default branch, and swapping kali-rolling for kali-last-snapshot in that same command moves you to the quieter one. Kali also ships a menu-driven alternative to editing files by hand: the kali-tweaks tool includes a "Network Repositories" section that does the same branch switch and enables extra branches like kali-experimental without touching a config file directly — useful if Jake would rather click a checkbox than remember sed syntax at 10pm.
Mirror choice matters too. The default http://http.kali.org/kali/ URI isn't one server — it's a load balancer that routes you to a working mirror automatically. If a past guide had you hardcode a specific regional mirror, and that mirror later goes stale or drops offline, you can end up with signature or fetch errors that have nothing to do with your keyring at all. Pointing the URI back at http.kali.org removes that variable.
ARM boards, cloud images, Docker, WSL, and offline installs
Jake actually asked about this next: he'd been eyeing a cheap ARM single-board computer to run as a dedicated diagnostic box at the shop instead of tying up the laptop every Saturday. "Does all of this apply the same way on one of those?" Ethan's answer was simple: yes. Kali publishes official images for ARM boards, cloud marketplaces (AWS, Azure, Linode), Docker, Vagrant, and Windows Subsystem for Linux, and every one of them uses the identical apt and keyring mechanism as a standard install. There's no separate "ARM version" of this fix or a "cloud version" — the same wget command and the same keyring path apply everywhere.
That's especially common to hit in Docker builds and CI pipelines, because container base images are cached and often haven't been rebuilt since before the key changed. Add the fix directly into a Dockerfile, before any other apt command: RUN wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg && apt update. In a Kali NetHunter chroot on Android, the same command works too — just make sure you're running it inside the chroot, not on the host device.
Offline installs are the one genuine exception. If Kali was installed without network access, it defaults to pulling packages only from the install media itself, with a commented-out deb cdrom:[...] line in sources.list and a note that the system was set up this way intentionally. A machine in that state was never checking a network key in the first place, so if you see this error there, it usually means someone already tried to enable network repositories partway — worth running sudo apt-cdrom add or switching fully to the network repository before troubleshooting the key any further.
What not to do, even though it's the most common advice online
Search this error and you'll find three recurring pieces of advice. All three "work," in the sense that apt update stops complaining. None of them is what you actually want.
"apt-key is dead," Ethan told Jake flatly when Jake read him a forum post suggesting it. "If a guide tells you to use apt-key add in 2026, close the tab. It's deprecated, it dumps every key into one giant global trust store with no way to scope it to one repository, and every current guide — including Kali's own — has moved away from it toward signed-by."
The second bad pattern is importing a key from a random public keyserver by its ID, rather than downloading it from archive.kali.org directly. A keyserver will hand you a key matching that ID, but it gives you no guarantee it's the legitimate Kali key rather than a same-ID collision or a malicious substitute — you're trusting an unrelated third party for something the vendor already publishes directly.
The third, and worst, is passing --allow-unauthenticated (or its cousin, disabling signature checks entirely) just to force the install through. That doesn't fix anything — it turns off the exact protection this whole system exists to provide, on every future update, not just this one. On a security-focused distribution, that's the one shortcut worth never taking.
- Our original writeup on this exact missing-key error
Covers the April 2025 key loss in more detail if you want the fuller backstory. - What's new in the latest Kali release
Worth a read after you're back up and running — see what changed before you upgrade further.
If the one-line fix doesn't clear it
Work down this list in order — cheapest and least disruptive first:
Check the date, then the network. Rule out clock skew and a filtered connection (both covered above) before touching anything else — they masquerade as key errors but no key fix will resolve them.
Try a different mirror. If your sources.list or kali.sources file points at a hardcoded regional mirror instead of Kali's load-balanced http.kali.org, that specific mirror may itself be stale or broken. Switch the URI back and retry.
Clear the local package cache. sudo rm -rf /var/lib/apt/lists/* followed by sudo apt update forces a completely fresh download of the index files, ruling out a locally corrupted cache as the cause.
Confirm you're not on an unofficial or altered image. If this is a third-party pre-built VM or a heavily customized ISO rather than an official Kali image, its repository setup may not match what's documented here at all — that's outside what any keyring fix can address.
⚠️ What we can't fix for you
If the machine can't reach archive.kali.org at all — no internet, or a network that blocks it outright — no command in this post will pull a current key onto it. You'll need to grab the keyring file on a connected machine and transfer it over manually, or reinstall from current media.
Every method, compared
| Method | Fixes the real cause? | Use it when |
|---|---|---|
| wget the current keyring (this post) | Yes | Almost always — this is the vendor-documented fix |
apt modernize-sources |
Partially | After the key fix, to move onto the current sources format |
apt-key add |
No — masks it | Never — deprecated, avoid entirely |
| Random keyserver import | No — unverifiable | Never — no guarantee of the key's origin |
--allow-unauthenticated |
No — disables checking | Never |
| Full reinstall from current ISO | Yes, but drastic | Only if the install is unofficial or heavily altered |
Stopping this from happening again
The single best habit is simply not letting a Kali install go untouched for months at a time. Run sudo apt update && sudo apt full-upgrade regularly, and the kali-archive-keyring package updates itself along with everything else — you'll rarely see this error on a machine that's kept current.
If Jake wants to be genuinely hands-off about it, a simple monthly cron entry does the job without him having to remember: sudo crontab -e, then add a line like 0 9 1 * * apt update && apt full-upgrade -y to run it automatically on the first of each month. It won't survive a key change that happens the same week as a long offline gap, but it closes most of the ordinary "I forgot" window that causes this in the first place.
🙋♂️ Jake's Reality Check
"So I just do this every time I haven't touched the VM in a while?"
Pretty much. Ethan's rule for Jake now: update the VM on Thursday night, not Saturday morning. If something's stale, there's time to fix it without a customer watching.
Frequently asked questions
What does NO_PUBKEY actually mean?
It means apt found the signed InRelease file from the repository but doesn't have a local copy of the public key needed to verify that signature, so it can't confirm the file is genuinely from Kali.
Is my Kali installation compromised or hacked?
No. This error is apt correctly refusing to trust a repository until it has a current key — it's the system working as designed, not a sign of intrusion.
Why did Kali's signing key change in the first place?
The prior key was lost in April 2025, forcing a new one onto the archive. Separately, Kali's documentation says the signing key gets extended or replaced roughly every two to three years as routine maintenance, so this isn't a one-time event.
Do I need to reinstall Kali to fix this?
No. On an official Kali image, refreshing the keyring file with the documented wget command resolves it without touching anything else on the system.
What's the difference between kali.sources and sources.list?
kali.sources is the newer, multi-line deb822-style configuration format introduced with Kali 2026.2. sources.list is the older single-line format used before that. Both point at the same keyring file, just written differently.
Will apt-key add fix it?
It can technically clear the error, but apt-key is deprecated, adds the key to a system-wide trust store instead of scoping it to Kali's repository, and isn't the method current guidance recommends.
Is it safe to use --allow-unauthenticated as a workaround?
No. It disables the exact signature check this whole system exists to enforce, for every future update, not just the current one.
Why do I get NO_PUBKEY on one machine but not another?
Whichever machine hasn't run apt update since the key changed still has the old keyring cached. A machine you update regularly usually picks up the new key automatically as part of a routine upgrade.
Does this affect Kali running in Docker, WSL, ARM boards, or cloud images?
Yes, in exactly the same way — all of them use the same apt and keyring mechanism as a full install, so the identical fix applies regardless of platform.
What if wget or curl also fails or times out?
That points to a network or DNS problem reaching archive.kali.org rather than a key problem. Check basic connectivity first, and consider a different network if one is available.
How do I know which sources file my system uses?
Run ls /etc/apt/sources.list.d/kali.sources. If it exists, you're on the current format; if not, check /etc/apt/sources.list for the older, single-line entry instead.
Can I just switch to a different mirror to fix this?
Only if a bad or stale mirror was the actual cause, which is uncommon. In most cases the key itself is the issue, and switching mirrors alone won't resolve it.
Will this happen again in the future?
Yes, eventually — key rotation is a recurring part of how Kali maintains repository security. Keeping the system updated regularly, or automating that update, is what prevents it from surprising you again.
Does apt full-upgrade fix outdated keyrings automatically?
Yes, on a system that can already reach the repository — the kali-archive-keyring package updates itself along with a normal upgrade. This error happens specifically because the keyring is too stale for apt to even reach that step.
Should I switch to kali-last-snapshot to avoid this?
It won't make you immune to key rotation, but its slower, quarterly update cadence means fewer moving parts overall, which some people find easier to keep current.
Revision note. Written September 2026, covering Kali installations on both the current deb822-style kali.sources format (2026.2 and newer) and the older single-line sources.list format, across standard, ARM, cloud, Docker, WSL, and NetHunter installs. This will need a fresh look whenever Kali next rotates or replaces the signing key, or changes the sources format again. If you landed here at 11pm with a client demo tomorrow morning, take a breath — this one really is a ten-second fix.Happy breaking as usual, with care!