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:

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

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

2. Export 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

3. Alternatively, 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

4. Ensure proper file permissions:

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

5. Update 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:

1. Download 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

2. Set standard world-readable permissions:

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

3. Edit 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

4. Re-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:

1. Execute 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

2. Convert created keyrings to standard permissions:

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

3. Run 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:

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

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

2. Export the key to an ASCII-armored file:

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

3. Transfer missing-key-<KEY_ID>.asc to the air-gapped machine using secure media (USB/SCP bastion host).
4. On 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

5. Test 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:

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

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

2. Export the key into the local keyring directory:

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

3. Alternative 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

4. Fix file permissions:

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

5. Test 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:

1. Pass 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>

2. Alternatively, 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

3. Apply standard permissions:

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

4. Confirm 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:

1. Attempt 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>

2. Export key to the modern keyring directory:

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

3. Correct file ownership and permissions:

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

4. Verify 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:

1. Extract 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

2. Remove the key from the legacy master file:

sudo apt-key del <KEY_ID>

3. Update 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

4. Update file permissions:

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

5. Run 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:

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

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

2. Remove old list file:

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

3. Create a modern .sources file:

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

4. Populate 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

5. Test 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:

1. Convert 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

2. Overwrite the original misformatted file:

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

3. Set standard read permissions:

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

4. Re-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:

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

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

2. Export updated key back into your dedicated keyring location:

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

3. If 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

4. Apply read permissions:

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

5. Test 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:

1. Remove empty 0-byte keyring files:

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

2. Test 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

3. Remove any corrupted keyring flagged by the test loop:

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

4. Re-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

5. Verify 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:

1. Reset directory ownership to root:

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

2. Ensure directories are executable and readable by all users:

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

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

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

4. Confirm 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

Network Drive Mapping Lost After Reboot: Credentials Fix

WireGuard Handshake Failed: Keys and Time Sync Troubleshooting

IPv4 vs IPv6 Conflict Causing Slow Websites: Fix

Embed Guide on Your Website