Interactive Troubleshooter

Published: Sep 13, 2026

Ubuntu Apt Update GPG Error NO_PUBKEY: Fix

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

This interactive diagnostic tree resolves the Ubuntu APT 'GPG error: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY' error. It details key importing mechanisms via trusted.gpg.d, keyrings, keyservers, proxy bypass, and legacy deprecation handling.

Full Diagnostic Tree & Step-by-Step Overview

What specific scenario or error environment are you encountering during 'sudo apt update'?

Standard PPA or Third-Party Repository Missing Key (Single or Multiple NO_PUBKEY error)
Keyserver Connection Timeout or Port 11371 Firewall Blocking
Legacy 'apt-key add' Deprecation Warning / Ubuntu 22.04+ Keyring Migration
EXPKEYSIG / Key Expired / Corrupted Keyring File in /etc/apt/trusted.gpg.d/

Select the exact repository origin and key acquisition method available:

Standard Launchpad PPA repository key missing
Third-party vendor repository providing a direct HTTPS .gpg/.asc key URL
Multiple NO_PUBKEY errors simultaneously across several repositories
Air-gapped / Offline machine unable to fetch keys online

Fix Missing Launchpad PPA Keys via Modern Keyring Directory

Solution:

Root Cause: Missing Launchpad PPA Public Key in GPG Truststore

When adding a PPA or custom repository, APT checks the release file's cryptographic signature against keys stored in /etc/apt/trusted.gpg.d/ or individual keyrings defined in /etc/apt/keyrings/. If the signature was generated by a key missing from your system, APT throws the

W: GPG error: ... The following signatures couldn't be verified because the public key is not available: NO_PUBKEY <KEY_ID>

warning and refuses to trust package indexes.

Diagnostic Verification:

Execute sudo apt update and identify the 16-character hex string following NO_PUBKEY (e.g., 8C47BE8E75BCA694):

bash
sudo apt update | grep NO_PUBKEY

Step-by-Step Fix:

1Create the secure keyrings directory if it does not exist:

sudo mkdir -p -m 0755 /etc/apt/keyrings

2Export the missing key directly from the Ubuntu Keyserver using OpenPGP format:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys <KEY_ID>

gpg --export <KEY_ID> | sudo tee /etc/apt/keyrings/ppa-key.gpg > /dev/null

3Alternatively, fetch directly via curl in a de-armored binary format:

curl -sL "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x<KEY_ID>" | sudo gpg --dearmor -o /etc/apt/keyrings/ppa-key.gpg

4Ensure proper file permissions:

sudo chmod 644 /etc/apt/keyrings/ppa-key.gpg

5Update software sources and verify:

sudo apt update drop-in warnings should now disappear.

Prevention & Long-Term Monitoring:

Use add-apt-repository on modern Ubuntu releases (22.04 LTS and 24.04 LTS), which automatically handles key placement inside /etc/apt/keyrings/ without global trust escalation.

Fix Vendor Repository Missing Key via Direct URL Import

Solution:

Root Cause: Unlinked Third-Party GPG Armor Key in APT Sources

Third-party software distributors (e.g., Docker, Google Chrome, Spotify) host dedicated .asc or .gpg files on web servers. If the system's /etc/apt/sources.list.d/<repo>.list file does not specify a signed-by directive, or if the referenced file in /etc/apt/keyrings/ is missing or corrupted, APT cannot validate repository manifests.

Diagnostic Verification:

Inspect the corresponding source file in /etc/apt/sources.list.d/ to locate the target repo and verify if [signed-by=...] is present:

bash
cat /etc/apt/sources.list.d/*.list

Step-by-Step Fix:

1Download the ASCII-armored key and convert it to OpenPGP binary format using gpg --dearmor:

curl -fsSL https://vendor.example.com/repo/gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/vendor-archive-keyring.gpg

2Set standard world-readable permissions:

sudo chmod 644 /etc/apt/keyrings/vendor-archive-keyring.gpg

3Edit the target source list entry to reference the key:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/vendor-archive-keyring.gpg] https://vendor.example.com/repo stable main" | sudo tee /etc/apt/sources.list.d/vendor.list

4Re-synchronize package lists:

sudo apt update

Prevention & Long-Term Monitoring:

Review the Ubuntu Debian Repository Format Documentation to ensure all third-party lists enforce individual signed-by paths rather than writing to legacy global /etc/apt/trusted.gpg files.

Bulk Fix Multiple Missing NO_PUBKEY Errors via Loop Script

Solution:

Root Cause: Accumulated Untrusted Repositories After OS Upgrade

After upgrading Ubuntu distributions (e.g., from 20.04 to 22.04 or 24.04), package manager trust stores may be cleared or invalidated, leaving multiple PPA and third-party sources without corresponding public keys installed.

Diagnostic Verification:

Collect all missing key strings simultaneously using apt update output parsing:

bash
sudo apt update 2>&1 | grep -oP 'NO_PUBKEY \K[0-9A-F]+'

Step-by-Step Fix:

1Execute an automated one-line shell loop to retrieve and install every missing key into /etc/apt/trusted.gpg.d/ or /etc/apt/keyrings/:

sudo apt update 2>&1 | grep -oP 'NO_PUBKEY \K[0-9A-F]+' | sort -u | while read key; do echo "Fetching key: $key"; sudo gpg --no-default-keyring --keyring /etc/apt/keyrings/imported-$key.gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys "$key"; done

2Convert created keyrings to standard permissions:

sudo chmod 644 /etc/apt/keyrings/imported-*.gpg

3Run APT update to confirm full resolution:

sudo apt update verify that no NO_PUBKEY lines remain.

Prevention & Long-Term Monitoring:

Audit existing PPAs prior to performing major distribution upgrades using ppa-purge to clean obsolete sources.

Fix NO_PUBKEY Error on Air-Gapped / Offline Systems

Solution:

Root Cause: Missing GPG Keys on Systems Without Direct Internet Access

Air-gapped enterprise Linux servers cannot query online HKP key servers or vendor HTTPS endpoints directly. When updating repositories from local mirrors or enterprise repository caches, APT still requires valid public key binaries stored locally.

Diagnostic Verification:

Check key verification errors on the offline host:

bash
sudo apt update

Note the missing 16-character KEY_ID (e.g., 3B4FE6ACC0B21F32).

Step-by-Step Fix:

1On an internet-connected workstation, download the missing key from the public keyserver:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys <KEY_ID>

2Export the key to an ASCII-armored file:

gpg --armor --export <KEY_ID> > missing-key-<KEY_ID>.asc

3Transfer missing-key-<KEY_ID>.asc to the air-gapped machine using secure media (USB/SCP bastion host).

4On the air-gapped machine, import and convert the key to binary keyring format:

cat missing-key-<KEY_ID>.asc | sudo gpg --dearmor -o /etc/apt/keyrings/offline-key-<KEY_ID>.gpg

sudo chmod 644 /etc/apt/keyrings/offline-key-<KEY_ID>.gpg

5Test APT resolution against your local repository mirror:

sudo apt update

Prevention & Long-Term Monitoring:

Bundle repository GPG keyrings inside internal RPM/DEB provisioning packages deployed via Ansible or Puppet during system bootstrapping.

Identify the network protocol or firewall restriction obstructing the key server:

Firewall blocking outbound HKP port 11371
Corporate HTTP/HTTPS Proxy server blocking keyserver traffic
DNS Resolution failure or HKP keyserver pool downtime

Bypass Port 11371 Firewall via Standard HTTPS HKPS Port 443

Solution:

Root Cause: Outbound Network Filtering on HKP Port 11371

By default, legacy GPG commands use the HKP protocol on TCP port 11371. Enterprise firewalls and network security groups frequently block non-standard outbound ports, leading to connection timeouts (gpg: keyserver receive failed: Connection timed out).

Diagnostic Verification:

Test network connectivity to the keyserver on default port 11371:

bash
nc -zv keyserver.ubuntu.com 11371

If connection times out or is refused, the port is filtered by network policy.

Step-by-Step Fix:

1Force GPG to communicate over standard SSL/TLS port 443 using HKPS:

sudo gpg --keyserver hkps://keyserver.ubuntu.com:443 --recv-keys <KEY_ID>

2Export the key into the local keyring directory:

gpg --export <KEY_ID> | sudo tee /etc/apt/keyrings/imported-<KEY_ID>.gpg > /dev/null

3Alternative solution using HTTP Web Key Lookup via curl over port 443:

curl -sL "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x<KEY_ID>" | sudo gpg --dearmor -o /etc/apt/keyrings/imported-<KEY_ID>.gpg

4Fix file permissions:

sudo chmod 644 /etc/apt/keyrings/imported-<KEY_ID>.gpg

5Test updating package list:

sudo apt update

Prevention & Long-Term Monitoring:

Always specify hkps:// URLs with explicit port 443 in automated build scripts and Dockerfiles to avoid reliance on legacy port 11371.

Configure GPG Keyserver Retrieval Through Corporate Proxy

Solution:

Root Cause: Proxy Server Interception and Lack of GPG Environment Variables

In enterprise networks requiring outbound web access via proxy servers, standard command-line tools fail if proxy settings (http_proxy/https_proxy) are not explicitly passed to gpg or if SSL inspection certificates interfere with HTTPS handshakes.

Diagnostic Verification:

Run curl with your proxy configuration to verify proxy reachability:

bash
curl -x [http://proxy.company.com:8080](http://proxy.company.com:8080) -sI [https://keyserver.ubuntu.com](https://keyserver.ubuntu.com)

Step-by-Step Fix:

1Pass explicit proxy parameters directly into gpg command:

sudo gpg --keyserver-options http-proxy=http://proxy.company.com:8080 --keyserver hkps://keyserver.ubuntu.com --recv-keys <KEY_ID>

2Alternatively, use curl with system environment variables to fetch key via HTTP lookup API:

export http_proxy="http://proxy.company.com:8080"

export https_proxy="http://proxy.company.com:8080"

curl -sL "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x<KEY_ID>" | sudo gpg --dearmor -o /etc/apt/keyrings/proxy-key-<KEY_ID>.gpg

3Apply standard permissions:

sudo chmod 644 /etc/apt/keyrings/proxy-key-<KEY_ID>.gpg

4Confirm fix:

sudo apt update

Prevention & Long-Term Monitoring:

Add permanent proxy rules into /etc/environment or /etc/apt/apt.conf.d/80proxy for system-wide compliance.

Switch Keyserver Host and Fallback to Direct Public Mirror

Solution:

Root Cause: Keyserver Pool Outage or DNS Unreachable Error

keyserver.ubuntu.com or keys.gnupg.net can occasionally experience localized outages, high load rate-limiting, or DNS resolution failures (gpg: keyserver receive failed: Server indicated a failure).

Diagnostic Verification:

Perform a DNS lookup on the target keyserver:

bash
dig +short keyserver.ubuntu.com

Check if key resolution fails on Ubuntu's keyserver pool.

Step-by-Step Fix:

1Attempt fetching key from alternative tier-1 key servers over HKPS:

sudo gpg --keyserver hkps://pgp.mit.edu --recv-keys <KEY_ID>

Or try OpenPGP keyserver:

sudo gpg --keyserver hkps://keys.openpgp.org --recv-keys <KEY_ID>

2Export key to the modern keyring directory:

gpg --export <KEY_ID> | sudo tee /etc/apt/keyrings/alt-keyserver-<KEY_ID>.gpg > /dev/null

3Correct file ownership and permissions:

sudo chmod 644 /etc/apt/keyrings/alt-keyserver-<KEY_ID>.gpg

4Verify APT update functionality:

sudo apt update

Prevention & Long-Term Monitoring:

Rely primarily on vendor-hosted static HTTPS URLs for key distribution instead of dynamic public OpenPGP key servers.

Identify the exact keyring warning or migration state:

W: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8)
Migrating old repository config from /etc/apt/sources.list to dedicated keyrings
Debian/Ubuntu keyring format conversion (.asc/.pub to de-armored .gpg)

Migrate Keys from Legacy trusted.gpg to Dedicated Keyrings

Solution:

Root Cause: Deprecation of Global GPG Trust Model in APT (apt-key)

Starting in Ubuntu 22.04 LTS and Debian 11, the apt-key utility and global key storage file (/etc/apt/trusted.gpg) are deprecated for security reasons. Global trust allows any repository key added to sign packages for any other repository on the system. APT now issues warnings when keys reside in the legacy file.

Diagnostic Verification:

List keys currently stored in the deprecated master keyring:

bash
sudo apt-key list

Locate the target key's last 8 hex digits (e.g., d38b4796).

Step-by-Step Fix:

1Extract the specific legacy key from /etc/apt/trusted.gpg into an isolated file in /etc/apt/keyrings/:

sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --export <KEY_ID> | sudo tee /etc/apt/keyrings/migrated-<KEY_ID>.gpg > /dev/null

2Remove the key from the legacy master file:

sudo apt-key del <KEY_ID>

3Update the repository line in /etc/apt/sources.list or /etc/apt/sources.list.d/ to reference the new keyring:

Open file: sudo nano /etc/apt/sources.list.d/custom.list

Modify line: deb [signed-by=/etc/apt/keyrings/migrated-<KEY_ID>.gpg] http://repo.example.com/ubuntu focal main

4Update file permissions:

sudo chmod 644 /etc/apt/keyrings/migrated-<KEY_ID>.gpg

5Run sudo apt update to confirm the deprecation warning is cleared.

Prevention & Long-Term Monitoring:

Never run apt-key add in deployment scripts. Follow modern security guidelines from Ubuntu Security Documentation regarding repository signing isolation.

Convert Legacy Sources List Entries to Modern Deb822 Format

Solution:

Root Cause: Legacy One-Line Package Source Syntax Lack of Scope

Traditional single-line .list files inside /etc/apt/sources.list.d/ are being superseded by the structured Deb822 .sources format in modern APT versions, allowing explicit key binding and clearer metadata validation.

Diagnostic Verification:

Inspect existing single-line sources:

bash
cat /etc/apt/sources.list.d/example.list

Step-by-Step Fix:

1Ensure the repository public key exists in binary GPG format inside /etc/apt/keyrings/:

Path: /etc/apt/keyrings/example-archive-keyring.gpg

2Remove old list file:

sudo rm /etc/apt/sources.list.d/example.list

3Create a modern .sources file:

sudo nano /etc/apt/sources.list.d/example.sources

4Populate with Deb822 stanza structure:

Types: deb

URIs: https://repo.example.com/ubuntu

Suites: noble

Components: main

Signed-By: /etc/apt/keyrings/example-archive-keyring.gpg

5Test configuration validity:

sudo apt update

Prevention & Long-Term Monitoring:

Adopt Deb822 .sources files natively across infrastructure management tools such as Ansible apt_repository modules.

Convert ASCII-Armored (.asc) Keys to Binary Keyring (.gpg) Format

Solution:

Root Cause: APT Keyring Format Mismatch (ASCII Armor vs Binary GPG)

APT expects key files specified in signed-by or stored in keyring paths to be raw OpenPGP binary data. If an ASCII-armored text file (starting with -----BEGIN PGP PUBLIC KEY BLOCK-----) is saved directly with a .gpg extension without de-armoring, APT fails to read signatures.

Diagnostic Verification:

Determine the file type using the file command:

bash
file /etc/apt/keyrings/target-key.gpg

If output states PGP public key block Public-Key (ASCII), the key requires de-armoring.

Step-by-Step Fix:

1Convert the ASCII-armored key into standard binary OpenPGP format:

sudo gpg --dearmor -o /etc/apt/keyrings/target-key-fixed.gpg /etc/apt/keyrings/target-key.gpg

2Overwrite the original misformatted file:

sudo mv /etc/apt/keyrings/target-key-fixed.gpg /etc/apt/keyrings/target-key.gpg

3Set standard read permissions:

sudo chmod 644 /etc/apt/keyrings/target-key.gpg

4Re-run repository synchronization:

sudo apt update

Prevention & Long-Term Monitoring:

Always pipeline downloaded key files through gpg --dearmor when generating .gpg keyring files from remote HTTP endpoints.

Select the specific key state or truststore corruption observed:

EXPKEYSIG (The following signatures were invalid: key expired)
Corrupted or 0-byte key file inside /etc/apt/trusted.gpg.d/
GPG / APT key ring ownership and permission errors (Permission denied)

Refresh Expired Repository Signing Keys (EXPKEYSIG)

Solution:

Root Cause: Expired Repository Signing Key in Truststore

Repository maintainers periodically rotate GPG keys or extend key expiration dates for security compliance. If your local system retains an older copy of the key past its valid lifespan, APT outputs W: GPG error: ... EXPKEYSIG <KEY_ID> and rejects package manifests.

Diagnostic Verification:

Check expiration metadata for the offending key:

bash
gpg --keyring /etc/apt/keyrings/target-key.gpg --list-keys

Identify the expired key ID listed next to pub or sub entries.

Step-by-Step Fix:

1Fetch the renewed public key from the keyserver to replace the expired instance:

sudo gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys <KEY_ID>

2Export updated key back into your dedicated keyring location:

gpg --export <KEY_ID> | sudo tee /etc/apt/keyrings/target-key.gpg > /dev/null

3If the repository provides a dynamic update URL, download the fresh key directly:

curl -fsSL https://vendor.example.com/repo/gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/target-key.gpg

4Apply read permissions:

sudo chmod 644 /etc/apt/keyrings/target-key.gpg

5Test package list update:

sudo apt update

Prevention & Long-Term Monitoring:

Maintain automated system maintenance jobs to refresh keys periodically using gpg --refresh-keys.

Remove Corrupted Zero-Byte Keyring Files from trusted.gpg.d

Solution:

Root Cause: Corrupted Keyring Byte-Streams in /etc/apt/trusted.gpg.d/

Aborted downloads, network interruptions, or improper shell redirects (> instead of tee or binary streams written directly without de-armoring) can leave 0-byte or corrupted .gpg files inside /etc/apt/trusted.gpg.d/. APT attempts to parse every file in this folder, triggering fatal GPG parse errors.

Diagnostic Verification:

Scan /etc/apt/trusted.gpg.d/ for empty or non-GPG files:

bash
ls -la /etc/apt/trusted.gpg.d/

Note any files with size 0 bytes or unexpected text formats.

Step-by-Step Fix:

1Remove empty 0-byte keyring files:

find /etc/apt/trusted.gpg.d/ -type f -empty -delete

2Test integrity of remaining GPG keyrings:

for file in /etc/apt/trusted.gpg.d/*.gpg; do echo "Testing $file"; gpg --keyring "$file" --list-keys >/dev/null || echo "Corrupted file: $file"; done

3Remove any corrupted keyring flagged by the test loop:

sudo rm /etc/apt/trusted.gpg.d/corrupted-file.gpg

4Re-fetch missing keys using the proper de-armor sequence into /etc/apt/keyrings/:

curl -fsSL https://vendor.example.com/gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/fixed-key.gpg

5Verify APT synchronization:

sudo apt update

Prevention & Long-Term Monitoring:

Always verify HTTP response status codes (curl -f) before piping remote content into system keyring files.

Fix File Permissions and Access Control Lists on APT Keyrings

Solution:

Root Cause: Restrictive File Permissions Preventing _apt User Access

In recent Debian and Ubuntu versions, APT drops root privileges when downloading and verifying package indexes, running unprivileged as the _apt system user. If key files in /etc/apt/keyrings/ or /etc/apt/trusted.gpg.d/ are configured with restrictive permissions (e.g., 0600 owned by root:root), _apt cannot read the public key, resulting in NO_PUBKEY errors.

Diagnostic Verification:

Check file permissions across system keyring paths:

bash
ls -la /etc/apt/keyrings/
ls -la /etc/apt/trusted.gpg.d/

Verify if permissions restrict world-readability (missing r--r--r--).

Step-by-Step Fix:

1Reset directory ownership to root:

sudo chown -R root:root /etc/apt/keyrings /etc/apt/trusted.gpg.d

2Ensure directories are executable and readable by all users:

sudo chmod 755 /etc/apt/keyrings /etc/apt/trusted.gpg.d

3Apply world-readable 0644 permissions to all key files:

sudo chmod 644 /etc/apt/keyrings/* /etc/apt/trusted.gpg.d/*

4Confirm APT update succeeds under the _apt unprivileged sandbox:

sudo apt update

Prevention & Long-Term Monitoring:

Include explicit chmod 644 commands in automated setup scripts (Bash, Cloud-Init, Dockerfiles) after creating new keyring files.

Related Diagnostic Guides

Windows Update Error 0x80070002 Missing Files Diagnostic Guide

System Restore Failed 0x80070005 Antivirus Conflict Tree

Windows Photo Viewer Not Showing Thumbnails: Codec Diagnostic

Safe Mode Password Not Working With Microsoft Account Fix

Clipboard History Not Working Windows 11: Sync Service Tree

Subscribe to StepDiag

Embed Guide on Your Website