APT shows this warning when it cannot verify a repository's GPG signature, usually due to a missing, expired, or rotated signing key, or a wrong system clock. The repo is skipped until fixed.
The "An error occurred during the signature verification" warning indicates that APT could not verify the cryptographic signature of one or more repositories during `apt update`. APT uses GPG (GNU Privacy Guard) keys to confirm that package metadata is authentic and has not been tampered with in transit. When APT refreshes your package lists, it downloads each repository's `Release` file along with a detached signature (`Release.gpg`) or an inline-signed `InRelease` file. APT then checks that signature against the public key declared for that repository. If the matching key is missing, expired, or no longer trusted, verification fails and APT refuses to use the freshly downloaded metadata. The message means APT will fall back to the previously cached package lists for that repository instead of the new ones. The system keeps working, but you may miss security updates and new package versions from the affected repository, so the underlying key problem should be resolved rather than ignored.
First, capture the exact error so you know which repository and key are involved:
sudo apt updateRead the output carefully. APT usually names the repository URL and the missing/expired key ID, for example:
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used.
W: ... NO_PUBKEY B7B3B788A8D3785CNote the key ID and the repository URL or .list/.sources filename mentioned — you will use them in the next steps.
GPG signatures and APT Release files have validity windows. A badly wrong clock makes valid signatures look expired or not-yet-valid:
# Check current date/time and sync status
timedatectl statusIf the date is clearly wrong (off by days or years), enable automatic synchronization:
sudo timedatectl set-ntp trueIf the machine has no network time source, set it manually (use your real current time):
sudo timedatectl set-time "2026-05-29 14:30:00"Then re-run sudo apt update.
Match the failing URL from the error to a source entry on disk:
# Newer deb822-style sources
ls /etc/apt/sources.list.d/
grep -R "" /etc/apt/sources.list.d/ 2>/dev/null
# Classic one-line sources
cat /etc/apt/sources.listDecide whether the failing repo is an official Debian/Ubuntu archive (fix via keyrings in step 4) or a third-party/PPA repo (fix via the signed-by method in step 5). If you no longer need the repo at all, see step 6.
If the failing repository is an official Ubuntu or Debian archive, the distribution keyring package usually fixes it:
# Ubuntu official archives
sudo apt install --reinstall ubuntu-keyring
# Debian official archives
sudo apt install --reinstall debian-archive-keyringThese packages install the maintained keys into /usr/share/keyrings/, which the official source entries reference. Then refresh:
sudo apt updateIf apt install itself cannot run because the keyring repo is the one failing, download the matching .deb for your release from the distribution's website on a trusted machine and install it with sudo dpkg -i <file>.deb.
For PPAs and third-party repositories, install the key as a dearmored file and point the source at it with Signed-By. Do NOT use apt-key — it is deprecated and has been removed in Ubuntu 22.04+ / Debian 12+, so it no longer works there.
Download the publisher's key (use the exact URL from the repository's official instructions) and convert it to a keyring file:
sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://example.com/repo/key.asc \
| sudo gpg --dearmor -o /etc/apt/keyrings/example.gpgThen reference that keyring from the source entry.
For a deb822 .sources file (/etc/apt/sources.list.d/example.sources):
Types: deb
URIs: https://example.com/repo/ubuntu
Suites: jammy
Components: main
Signed-By: /etc/apt/keyrings/example.gpgOr for a classic one-line entry in /etc/apt/sources.list.d/example.list:
deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/repo/ubuntu jammy mainIf you only have a key ID (not a download URL), fetch it from a keyserver into the keyring file:
sudo gpg --no-default-keyring \
--keyring /etc/apt/keyrings/example.gpg \
--keyserver hkps://keyserver.ubuntu.com \
--recv-keys B7B3B788A8D3785CVerify the key fingerprint against the publisher's documentation before trusting it, then run sudo apt update.
If a repository keeps failing and you do not need its packages, removing it lets apt update finish cleanly:
# Inspect the entry first so you know what you are removing
cat /etc/apt/sources.list.d/problematic-repo.list
# Remove the dedicated source file
sudo rm /etc/apt/sources.list.d/problematic-repo.listIf the entry lives in the main file, comment it out instead of deleting blindly:
sudo nano /etc/apt/sources.list
# Prefix the offending 'deb'/'deb-src' line with '#'Then run sudo apt update. You can re-add the repository later with a correct key using the signed-by method in step 5.
Corrupted files in the APT lists directory can cause persistent verification failures. Clearing them forces a clean re-download and re-verification:
sudo rm -rf /var/lib/apt/lists/*
sudo mkdir -p /var/lib/apt/lists/partial
sudo apt updateThis is non-destructive (it only removes cached metadata, not installed packages) but the first update afterwards will be slower because all lists are fetched again.
apt-key is removed, not just deprecated: Older guides tell you to run apt-key add or apt-key adv --recv-keys. Avoid this. apt-key was deprecated in Debian 9 / Ubuntu 16.04 and the binary has been removed in Ubuntu 22.04+ and Debian 12+, where the command simply does not exist. Keys it previously added to /etc/trusted.gpg are also no longer consulted by default for new-style sources. Always install keys as dearmored files under /etc/apt/keyrings/ (or /usr/share/keyrings/ for packaged keys) and reference them with Signed-By / [signed-by=...].
Per-repository trust with signed-by: Scoping each key to the repository that needs it (via Signed-By) is more secure than a global trusted keyring, because a third-party key can then only validate its own repository rather than every source on the system.
Keyserver alternatives: keyserver.ubuntu.com is a load-balanced pool. If it times out, prefer hkps://keyserver.ubuntu.com (TLS) and only fall back to other pools if necessary. Always verify the retrieved key's fingerprint against the publisher's documentation before using it.
Mixing Debian and Ubuntu: If you intentionally use Debian repositories on Ubuntu (or vice versa), install both debian-archive-keyring and ubuntu-keyring, since each provides different signing keys.
Key rotation: Distributions and large third-party repos rotate signing keys periodically. If a previously working repo suddenly reports an unknown key, check the project's official announcements for the new key rather than disabling verification.
Proxies and SSL inspection: Behind a corporate proxy that intercepts TLS, APT may fail to fetch Release/InRelease files. Configure the proxy for APT in /etc/apt/apt.conf.d/proxy.conf:\n\n
\nAcquire::http::Proxy \"http://proxy.company.com:8080\";\nAcquire::https::Proxy \"http://proxy.company.com:8080\";\n\n\nOffline systems: To install a key on a machine with no keyserver access, export it on a connected, trusted machine and copy the dearmored keyring across — never re-enable apt-key for this:\n\n
\n# On a connected, trusted machine\ngpg --export B7B3B788A8D3785C | gpg --dearmor > example.gpg\n\n\nTransfer example.gpg to the offline machine, place it in /etc/apt/keyrings/, and reference it with Signed-By in the relevant source entry.
Date-validation workaround (discouraged): As a strictly temporary measure while diagnosing a genuine clock or stale-Release problem, you can tell APT to ignore the Release file's validity window:\n\n
\nsudo apt -o Acquire::Check-Valid-Until=false update\n\n\nThis weakens protection against replay/rollback attacks, so never make it permanent or apply it system-wide — fix the clock (step 2) or the upstream key instead.
E: Could not connect to proxy server
Could not connect to proxy server
E: Package 'package:i386' has no installation candidate
How to fix "Package package:i386 has no installation candidate" in apt
E: The value 'value' is invalid for APT::Default-Release
How to fix invalid APT::Default-Release value in APT
dpkg: error: unable to create new file 'path': Permission denied
How to fix dpkg permission denied errors in APT
subprocess installed post-removal script returned error exit status 1
How to fix "subprocess installed post-removal script returned error exit status 1" in APT