Fixing Kali Linux APT Signature Errors: A Diagnostic Guide for EXPKEYSIG and NO_PUBKEY

Recognizable condition: Running sudo apt update on a Kali Linux system fails with signature verification errors such as EXPKEYSIG or NO_PUBKEY that reference Kali repository keys, while Debian and third-party repositories update normally. Kali’s rolling-release model periodically rotates signing keys, and the local kali-archive-keyring package can lag behind that rotation. The useful takeaway is that these failures are usually fixed by refreshing the keyring or correcting the system clock—not by disabling signature checking.

Cause and Diagnostic Table

Symptom	Likely Cause	Verification
EXPKEYSIG for kali-archive-keyring	Repository key rotated; local keyring stale	apt-key list | grep -A1 'Kali Linux Repository'
NO_PUBKEY <keyid>	New signing key absent from local keyring	gpg --list-keys <keyid> returns nothing
Release file expired plus signature errors	System clock skew combined with key expiry	date; timedatectl
Hash sum mismatch after key fix	Partial mirror synchronization	apt update -o Acquire::CompressionTypes::Order::=gz

Ordered Checks

1. Confirm System Clock Accuracy

Run the following in a terminal. No elevated permissions are needed to read the status.

timedatectl

Confirm that the output shows System clock synchronized: yes. If the clock is off by hours or days, signature timestamps will appear expired even when the keyring is correct. This check is read-only.

2. Isolate Key-Related Errors

Run this in a terminal. It requires sudo because apt update writes to package indexes.

sudo apt update 2>&1 | grep -E "(EXPKEYSIG|NO_PUBKEY|expired)"

Look for lines that reference kali-rolling or Kali archive keys. If only third-party repositories appear, diagnose those separately. This command is read-only.

3. Check Installed Keyring Version

Run in a terminal. No sudo is required.

dpkg -l kali-archive-keyring

Note the version string. Kali documentation lists the current keyring version; treat any locally installed version older than the published one as suspect. On ARM images such as Raspberry Pi, the package may be named kali-archive-keyring-arm64—verify the package name matches your architecture.

4. Verify the Published Signing Key Fingerprint

Open the official Kali sources-list documentation at https://www.kali.org/docs/general-use/kali-linux-sources-list-repositories/ and locate the current archive signing key fingerprint. Then inspect the local keyring:

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

Compare the fingerprint character by character. Do not rely on memory or third-party mirrors for this value.

5. Test Mirror Reachability

Run in a terminal:

curl -I http://http.kali.org/kali/dists/kali-rolling/Release

Confirm that the response includes an HTTP 200 status. A 404 or timeout suggests a mirror or network problem rather than a key problem.

Fixes Tied to Findings

If the Keyring Package Is Outdated

When dpkg -l shows a stale kali-archive-keyring, reinstall it from a working mirror. Run in a terminal with sudo:

sudo apt install --reinstall kali-archive-keyring

This operation changes package state. If the same signature error blocks the reinstall, proceed to the manual bootstrap below.

If NO_PUBKEY Indicates a Missing New Key

When the repository has rotated to a key that is absent locally, bootstrap the keyring manually over HTTPS. First, back up the existing file so you can roll back:

sudo cp /usr/share/keyrings/kali-archive-keyring.gpg /usr/share/keyrings/kali-archive-keyring.gpg.bak

Then fetch and dearmor the published key:

wget -q -O - https://archive.kali.org/archive-key.asc | gpg --dearmor | sudo tee /usr/share/keyrings/kali-archive-keyring.gpg >/dev/null

Ensure /etc/apt/sources.list references this keyring explicitly with the signed-by option. A typical line looks like:

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

Rollback: restore the backup with sudo cp /usr/share/keyrings/kali-archive-keyring.gpg.bak /usr/share/keyrings/kali-archive-keyring.gpg.

If Clock Skew Is Present

When timedatectl shows the clock is unsynchronized, enable NTP and set the timezone. Replace <zone> with your region, for example America/New_York. Run with sudo:

sudo timedatectl set-ntp true
sudo timedatectl set-timezone <zone>

These commands change system time state. Confirm afterward that System clock synchronized: yes.

If a Mirror Is Failing

If curl -I fails or multiple mirrors return the same signature error, edit /etc/apt/sources.list and switch to a geographically closer or officially listed mirror. This changes package sources. Rollback by restoring the original file from backup.

Escalation Criteria

Escalate to the Kali forums or bug tracker when:

• kali-archive-keyring is current according to official documentation, but EXPKEYSIG persists after reinstall.
• The fingerprint published on kali.org does not match the repository Release.gpg.
• Multiple official mirrors show the same signature failure.
• apt update succeeds only with Acquire::AllowInsecureRepositories=true, which suggests a supply-chain problem requiring maintainer attention.

Verifying the Fix

After applying a fix, run sudo apt update again and confirm that no EXPKEYSIG, NO_PUBKEY, or expired-signature lines appear. Then check that the keyring version matches the current published version:

dpkg -l kali-archive-keyring

Cross-check the fingerprint once more against the official documentation. If Docker is available, a clean container test validates upstream keyring health without touching your host:

docker run --rm kalilinux/kali-rolling apt update

Finally, monitor /var/log/apt/term.log for future kali-archive-keyring upgrade entries so you can catch regressions early.

Limitations and Safety Notes

Do not use Acquire::AllowInsecureRepositories=true as a permanent fix; it defeats the trust model of a rolling release. Third-party repositories such as Docker, VS Code, or Google Chrome rotate keys independently and must be diagnosed separately. If a system has been offline for an extended period, the chain of trust may be broken because keyring updates are signed by the previous key; manual HTTPS bootstrap from kali.org is then required. After any kernel update triggered by the same repair, DKMS modules such as wireless or NVIDIA drivers may need to rebuild—schedule a reboot and run dkms status afterward. Package versions and fingerprints change over time; always verify current values against the official Kali documentation before acting.