How to Fix GPG Error: The Following Signatures Couldnt Be Verified in Ubuntu

Start by identifying which repository produced the warning, then fix that repository's key or configuration. Do not disable APT signature checks. The message The following signatures couldn't be verified means APT cannot confirm that repository metadata was signed by a key it trusts. Until the signature is verified, APT may refuse to use that source. Adding a random key or setting a source to trusted can hide the warning while removing the protection it is meant to provide.

For example, suppose sudo apt update reports NO_PUBKEY for a browser vendor's repository, while Ubuntu's own archive lines update successfully. The likely fix is to install that vendor's currently published signing key and scope it to that repository. Reinstalling Ubuntu's archive keyring would not solve a third-party key problem. The commands below are templates: replace example repository details with values from the software publisher's official instructions.

Read the exact error before changing keys

Run the update command and note the repository URL and the error code on the same output lines:

sudo apt update

APT normally identifies a source by its URL and release suite, such as noble or jammy. If more than one source is configured, it may show several errors. Match each message to its own repository before making a change. These common signatures point to different causes:

Check the system clock first when the error mentions time

Signatures and repository metadata have validity periods. A server restored from an old snapshot, a dual-boot computer, or a machine with a failed time service can have a clock far enough off to make current metadata appear invalid. Check the system time:

timedatectl status

Confirm that the displayed date and time are accurate and that time synchronization is active. If the clock is wrong, correct the host's time service or enable the configured network time synchronization method, then retry sudo apt update. Avoid manually setting an approximate date: the clock should reflect the real time. A time correction will not repair a missing or expired repository key, so if the message remains a NO_PUBKEY or EXPKEYSIG error, continue with the relevant key steps.

Fix a missing or expired third-party repository key

Ubuntu's current guidance recommends storing third-party keys in a dedicated keyring and referencing that key from the matching source with Signed-By. This limits which key can authenticate that repository. Ubuntu describes this approach in its third-party repository guide and APT documents how Signed-By scopes verification in the sources.list manual.

1. Find the source that generated the error

List repository entries and search for the host shown in the APT output:

grep -RniE '^[[:space:]]*(deb|URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Ubuntu 24.04 and later commonly use deb822 files ending in .sources; older releases commonly use one-line files ending in .list. The Ubuntu package management documentation describes these source formats. Do not edit the Ubuntu archive entry to repair an unrelated vendor repository.

2. Get and verify the publisher's current key

Open the software publisher's official repository setup page and confirm that it names the repository URL, supported Ubuntu release, signing-key download location, and full key fingerprint. Download the key only from a source the publisher identifies. Compare the full fingerprint, not only the short hexadecimal ID shown after NO_PUBKEY. The APT security manual emphasizes obtaining keys through a trusted channel; trusting the wrong key would undermine repository verification.

The following example uses an ASCII-armored key. Replace the example URL and file name with the publisher's official values:

curl -fsSLo /tmp/vendor-archive.asc https://packages.vendor.example/ubuntu/archive-key.asc
gpg --show-keys --with-fingerprint /tmp/vendor-archive.asc

Proceed only when the displayed fingerprint matches the one the publisher documents. Convert it to a binary keyring and place it in APT's local keyring directory:

sudo install -d -m 0755 /etc/apt/keyrings
gpg --dearmor --output /tmp/vendor-archive.gpg /tmp/vendor-archive.asc
sudo install -m 0644 /tmp/vendor-archive.gpg /etc/apt/keyrings/vendor-archive-keyring.gpg

The example domain is illustrative and will not download a real vendor key. Use the exact verified key URL supplied by the actual software publisher. Do not use a keyserver search result as a substitute for confirming key ownership.

3. Scope the key in the repository source

For a one-line .list entry, the pattern is:

deb [signed-by=/etc/apt/keyrings/vendor-archive-keyring.gpg] https://packages.vendor.example/ubuntu noble main

For a deb822 .sources file, the corresponding fields look like this:

Types: deb
URIs: https://packages.vendor.example/ubuntu
Suites: noble
Components: main
Signed-By: /etc/apt/keyrings/vendor-archive-keyring.gpg

These are templates, not universally valid source entries. Keep the URI, suite, and components from the vendor's official setup instructions; a wrong Ubuntu codename can create package conflicts even when the key is valid. Ensure the keyring path matches the file you installed. The keyring must be readable by APT's unprivileged _apt user, which is why the example installs it with mode 0644. Remove or correct duplicate entries for the same repository so an old unscoped entry does not continue to produce the warning.

APT's apt-key command is deprecated for ordinary repository setup. Avoid guides that add third-party keys globally with apt-key adv or place every vendor key in a common trusted keyring. A scoped Signed-By entry makes the trust relationship clearer and reduces the effect of trusting one repository key.

If the warning is for Ubuntu's own archive

First check that the repository suite matches your installed Ubuntu release and that the system clock is correct. Ubuntu archive signing keys are supplied by the ubuntu-keyring package. If the installed keyring is damaged or outdated, and APT can still download and verify packages from a valid configured Ubuntu source, reinstall it with:

sudo apt install --reinstall ubuntu-keyring

Then run sudo apt update again. If the only failing source is an obsolete release archive or a mirror that is serving inconsistent metadata, reinstalling the keyring may not help. Check Ubuntu's release support and repository configuration before changing keys. Do not replace the Ubuntu archive key with a key downloaded from an unrelated site or disable verification to force an update.

Clear cached indexes only for a metadata mismatch

If APT reports BADSIG after a temporary network interruption or a mirror/proxy problem, the locally cached package lists may be incomplete or inconsistent. After confirming the configured source is legitimate, clear only the cached APT index files and fetch them again:

sudo rm -rf /var/lib/apt/lists/*
sudo apt update

This removes downloaded repository indexes, not installed packages. APT rebuilds the indexes on the next update. If BADSIG immediately returns, stop repeating the cleanup: check whether a network proxy, caching gateway, or mirror is rewriting or serving mismatched metadata, and check the repository status with its publisher. Repeatedly deleting indexes does not fix a signature that the repository itself publishes incorrectly.

Confirm the repair and keep the protection enabled

Run sudo apt update again and verify that the affected repository completes without NO_PUBKEY, EXPKEYSIG, BADSIG, or signature-verification warnings. Then check a package from that source with apt-cache policy package-name, replacing the name with an actual package. Confirm its candidate version comes from the expected repository before installing or upgrading it.

Do not use trusted=yes, allow-insecure=yes, --allow-unauthenticated, or similar options as a permanent fix. APT's signature check verifies that repository metadata is signed by a key you have chosen to trust; disabling it means APT can no longer provide that integrity check. The APT secure manual explains the archive authentication chain and its limits. If the publisher has withdrawn a repository, stopped signing metadata, or does not provide a verifiable key fingerprint, remove or disable that source instead of bypassing verification.

Documentation checked October 6, 2026. Ubuntu repository formats and key-management recommendations can vary by release; use your installed Ubuntu version's documentation and the repository publisher's current instructions.