Fix apt's 'Missing Signed-By' notice on Ubuntu

What "N: Missing Signed-By" means

The N: Missing Signed-By line that apt update prints is a notice, not an error. Your update still ran, and apt still installs packages from that source. The message says one repository entry does not name its own signing key, so apt checks that repository against every key in its global keyrings. To fix it, you add a Signed-By field that points at the one keyring that should sign that repository.

This is the line most people paste into a search box:

N: Missing Signed-By in the sources.list(5) entry for 'https://esm.ubuntu.com/apps/ubuntu'

The text in quotes is the repository address, its URI (uniform resource identifier), with any login details removed. It tells you which entry to fix. sources.list(5) is not a file on your disk. It is the name of the manual page that documents both source formats.

What do N:, W: and E: mean in apt output?

apt sorts every message into a level. The apt source code defines six levels: FATAL, ERROR, WARNING, NOTICE, AUDIT and DEBUG. The short prefix in front of each line tells you which one you are reading.

• E: is an error. Something failed, and apt usually stops.
• W: is a warning. apt continued, but something is probably wrong.
• N: is a notice. The apt source describes this level as "deprecation warnings, old fallback behavior".
• A: is an audit message, the lowest of these four. The source describes it as "future deprecation warnings, divergence from best practices".

The source comment for the notice level is direct. A notice "can be ignored by the client without further problems for some times, but he should consider fixing the problem." That is the honest answer to "is my server broken". It is not broken today. The notice points at behavior that apt plans to stop supporting.

On apt 3.x you may see long labels instead of letters: Notice: instead of N:, and Warning: instead of W:. The apt 3.2.0 source picks the label from the APT::Output-Version setting. It prints the short letters below version 30 and the long labels from 30 up. Both forms mean the same level, so search your output for the words Missing Signed-By, not for the prefix.

Which Ubuntu versions print the Missing Signed-By notice?

apt added this notice for deb822 sources in apt 2.7.2. Ubuntu 24.04 LTS (long-term support) ships apt 2.7.14build2, so 24.04 prints it. The Ubuntu Discourse report from December 2024 came from a machine upgraded from 22.04 to 24.04. A DigitalOcean Community question shows the same line for a provider mirror, http://mirrors.digitalocean.com/ubuntu, on a machine that went from 22.04 to 24.04 through an interim 23.x release.

Ubuntu 26.04 LTS was released on 23 April 2026. As of October 2026, packages.ubuntu.com lists apt 3.2.0 for it. In the apt 3.2.0 source, the check works like this:

• An entry in a deb822 .sources file with no Signed-By gets the message at NOTICE level.
• An entry in a one-line .list file with no Signed-By gets it at AUDIT level. apt then adds Consider migrating all sources.list(5) entries to the deb822 .sources format and Some sources can be modernized. Run 'apt modernize-sources' to do so.

That is the upstream code, not a captured 26.04 run. Ubuntu can patch apt, so check what your own machine prints. The two entry formats are explained in how deb822 .sources files and one-line .list files differ, so this guide does not teach them again.

The reports share one pattern: the notice shows up after a release upgrade. An upgrade carries old source files and old keys forward into a newer apt that checks for Signed-By. If you are planning that move, start with the Ubuntu 24.04 to 26.04 upgrade guide. Clear this notice first, and any new message in the upgrade output is easier to spot.

Why apt prints it: one keyring trusted for everything

Each repository publishes a signed Release file, and apt checks that signature before it trusts the package lists. The Signed-By field tells apt which keys may produce that signature. When the field is missing, apt falls back to a global set. The sources.list(5) manual says it plainly: "all keys in the trusted keyrings are considered valid signers for this repository". With no keyring named, that set is the /etc/apt/trusted.gpg file plus every keyring in /etc/apt/trusted.gpg.d/.

This is the cause of the notice. A key you added for one vendor can vouch for any repository on the machine, including the Ubuntu archive itself, because apt has no record of which key belongs to which source.

apt is moving away from that model. The NEWS entry for apt 2.9.24 (January 2025) says entries without Signed-By are deprecated, and that "This deprecates the /etc/apt/trusted.gpg.d directory." The same entry says /etc/apt/trusted.gpg is no longer trusted at all. The apt maintainer has also written about a plan to remove trusted.gpg support. No date has been given for either change, so do not plan around one.

How do I find every entry without Signed-By?

Start with the list apt prints. Then look at the files behind it.

sudo apt update 2>&1 | grep 'Missing Signed-By'
ls -l /etc/apt/sources.list.d/ /etc/apt/trusted.gpg.d/
grep -H Signed-By /etc/apt/sources.list.d/*.sources
grep -L Signed-By /etc/apt/sources.list.d/*.sources
grep -H '^deb' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null

The first command prints one line per entry that lacks a key. A clean system prints nothing. The grep -L line lists .sources files with no Signed-By anywhere in them. A .sources file can hold several entries, called stanzas, separated by blank lines. So a file that appears in the grep -H output can still contain one stanza without the field. The last line shows one-line entries, which carry a key only if [signed-by=...] appears after deb.

To match a URI from the apt update output to the file that holds it, search for part of the address:

grep -rn 'esm.ubuntu.com/apps' /etc/apt/sources.list /etc/apt/sources.list.d/

The right key depends on who signs the repository, so the fixes below are split by source type.

Read a keyring before you trust it

Never point Signed-By at a file you cannot identify. A keyring is a file of GPG (GNU Privacy Guard) public keys, and its file name proves nothing about what is inside. gpg --show-keys reads a key file and prints the same details that gpg --list-keys prints for keys stored in your own keyring. --with-fingerprint adds the full fingerprint to that output.

gpg --show-keys --with-fingerprint /usr/share/keyrings/ubuntu-archive-keyring.gpg
for f in /etc/apt/trusted.gpg.d/*; do echo "== $f"; gpg --show-keys --with-fingerprint "$f"; done

Read the uid line of each key. It should name the organisation that runs the repository. Then compare the fingerprint with the one the vendor publishes in its install documentation. If a key has no owner you recognise and no source you can find, do not reference it. Treat it as a reason to clean up trusted.gpg.d.

apt reads keyrings as the unprivileged _apt system user. The sources.list(5) manual says the file must be readable by that user, so give every keyring you place by hand mode 644 and check it:

ls -l /usr/share/keyrings/ /etc/apt/keyrings/

These apt keyrings are separate from the certificate store that curl and browsers use for TLS (transport layer security). If you need a private certificate authority for HTTPS, that is a different job, covered in adding your own CA to the Ubuntu trust store.

Fix 1: Ubuntu Pro and ESM entries

ESM (Expanded Security Maintenance) repositories come with an Ubuntu Pro subscription, and the Pro client writes their source files for you. If you are not sure what Pro adds to a machine, read what Ubuntu Pro does on a server first.

The Pro client source picks the file layout by Ubuntu release. For xenial, bionic, focal and jammy (22.04 and older) it writes a .list file and exports the key into /etc/apt/trusted.gpg.d/, with no Signed-By. For every newer release it writes a deb822 file at /etc/apt/sources.list.d/ubuntu-NAME.sources, with Signed-By pointing into /usr/share/keyrings. The ESM key files there are ubuntu-pro-esm-apps.gpg and ubuntu-pro-esm-infra.gpg. Canonical's ESM documentation shows this line for 24.04:

Signed-By: /usr/share/keyrings/ubuntu-pro-esm-apps.gpg

Going by that source, a fresh 24.04 or 26.04 install should not print the notice for ESM. A machine upgraded from 22.04 can, because it may carry the old layout forward. The Discourse report shows exactly this case: an ubuntu-esm-apps.sources file with no Signed-By, after a 22.04 to 24.04 upgrade. The fix accepted in that thread added this line:

Signed-By: /etc/apt/trusted.gpg.d/ubuntu-pro-esm-apps.gpg

That silences the notice. It also names a key in the directory apt has deprecated, so prefer the copy in /usr/share/keyrings if your system has one. Check before you edit anything:

ls -l /usr/share/keyrings/ubuntu-pro-esm-*.gpg /etc/apt/trusted.gpg.d/ubuntu-pro-esm-*.gpg
grep -H -e URIs -e Signed-By /etc/apt/sources.list.d/ubuntu-esm-*.sources
gpg --show-keys --with-fingerprint /usr/share/keyrings/ubuntu-pro-esm-apps.gpg

If /usr/share/keyrings/ubuntu-pro-esm-apps.gpg exists and its uid names Canonical's ESM key, open /etc/apt/sources.list.d/ubuntu-esm-apps.sources. Add Signed-By: /usr/share/keyrings/ubuntu-pro-esm-apps.gpg on its own line inside the stanza, next to the URIs: line. Do the same in ubuntu-esm-infra.sources with ubuntu-pro-esm-infra.gpg. If the key exists only in /etc/apt/trusted.gpg.d/, copy it into /etc/apt/keyrings with the steps in Fix 3 and reference the copy.

The Pro client manages these files and may rewrite them later. On 24.04 and newer, the file it writes already contains Signed-By, so a rewrite does not bring the notice back.

Fix 2: provider mirror entries

Many VPS providers point apt at their own copy of the Ubuntu archive. The DigitalOcean report names mirrors.digitalocean.com/ubuntu. DigitalOcean's mirror documentation does not mention Signed-By or keys at all, so this fix rests on apt's and Ubuntu's own docs. A mirror of the Ubuntu archive serves the archive's signed Release file, so the key to name is the Ubuntu archive key. The next apt update proves it, as shown at the end of this section.

On 24.04 and newer, Ubuntu's documentation shows the default repositories in /etc/apt/sources.list.d/ubuntu.sources with this line:

Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Find the stanza or line that names the mirror:

grep -rn 'mirrors.digitalocean.com' /etc/apt/sources.list /etc/apt/sources.list.d/
lsb_release -cs

If the mirror is in a .sources file, add the Signed-By line to that stanza. A finished stanza on a 24.04 machine looks like this. lsb_release -cs prints your release codename: noble on 24.04 and resolute on 26.04.

Types: deb
URIs: https://mirrors.digitalocean.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

If the mirror is a one-line entry in a .list file, put the option in square brackets after deb:

deb [signed-by=/usr/share/keyrings/ubuntu-archive-keyring.gpg] https://mirrors.digitalocean.com/ubuntu/ noble main restricted universe multiverse

Now run sudo apt update. If the keyring matches, the mirror fetches with Hit: or Get: lines and no notice. If you named the wrong keyring, apt rejects that source with a signature error instead, which tells you the key does not match the repository.

Fix 3: third-party vendor repositories

Vendor repositories are where the global keyring is riskiest, because their keys come from outside Ubuntu and were often added by an install script you did not read. The apt-secure(8) manual recommends /etc/apt/keyrings for local keys that you manage, and /usr/share/keyrings for keys managed by packages. A vendor key you added by hand belongs in /etc/apt/keyrings.

First identify the vendor's key in trusted.gpg.d with the gpg --show-keys loop above. Then copy it into place. In these commands, replace vendor with a name you will recognise later.

sudo install -d -m 755 /etc/apt/keyrings
sudo install -m 644 /etc/apt/trusted.gpg.d/vendor.gpg /etc/apt/keyrings/vendor.gpg
gpg --show-keys --with-fingerprint /etc/apt/keyrings/vendor.gpg

If the vendor's install docs publish a keyring download, a fresh copy from that page is better than an old file. Either way, compare the fingerprint with the one the vendor publishes.

Next, name the key in the source entry. In a .sources stanza, add this line:

Signed-By: /etc/apt/keyrings/vendor.gpg

In a one-line .list entry, add [signed-by=/etc/apt/keyrings/vendor.gpg] after deb. Run sudo apt update and confirm that the vendor source fetches with no notice. Then remove the global copy and update again:

sudo rm /etc/apt/trusted.gpg.d/vendor.gpg
sudo apt update

This last step is the point of the fix. A key left in trusted.gpg.d is still trusted for every source that lacks Signed-By. If the second apt update shows a signature error for another entry, that entry was relying on the same global key, and it needs the same Signed-By line.

One more case matters on 26.04. The apt 2.9.24 NEWS entry says keys in the single legacy file /etc/apt/trusted.gpg are no longer trusted. If an old vendor key lives only there, get a fresh copy from the vendor into /etc/apt/keyrings before you rely on that repository after the upgrade.

On apt 3.x: what apt modernize-sources changes

apt 2.9.26 (January 2025) added a command that does much of this work for you: apt modernize-sources. It is part of apt 3.2.0 on 26.04. Ubuntu 24.04 ships apt 2.7.14, which is older than 2.9.26, so expect the command to be missing there and make the edits by hand.

The apt 3.2.0 source shows what it does:

• It processes only files ending in .list, plus the main /etc/apt/sources.list.
• It rewrites each one as a deb822 .sources file and saves the original as a .list.bak file.
• It adds Signed-By values where it can work them out. Where it cannot, it prints Could not determine Signed-By for URIs: ..., Suites: ....
• It carries over the signed-by and trusted bracket options. Any other option inside [ ] must be moved by hand, and the command prints a reminder to do that.

Read the first point again. The N: notice comes from .sources entries, and modernize-sources does not touch those. On 26.04 it clears the A: audit lines from old .list entries. An N: line about a .sources entry still needs the hand edit from Fix 1, 2 or 3.

Back up the apt directory, then run the command:

sudo cp -a /etc/apt /root/etc-apt-backup
sudo apt modernize-sources

It prints The following files need modernizing: and a file list, then asks Rewrite N sources? with yes as the default. Answer no the first time. In the source, a no runs a simulation, so you see the planned result without any change on disk. Run it again and answer yes when the output looks right. Then check the result:

ls /etc/apt/sources.list.d/
grep -H Signed-By /etc/apt/sources.list.d/*.sources
sudo apt update 2>&1 | grep 'Missing Signed-By'

A healthy result has a .sources file next to each .list.bak backup, a Signed-By line in every stanza, and no output from the last command. Any URI that appeared in a Could not determine Signed-By line needs Fix 3.

When is it safe to leave the notice alone?

Leave it for now when two things are true: you know which key signs the repository, and every file in /etc/apt/trusted.gpg.d/ belongs to an owner you recognise. The notice level means apt still works as it always has. The one-line format is deprecated, and the sources.list(5) manual says it "may eventually be removed, but not before 2029." No removal date exists for trusted.gpg.d.

Fix it now when trusted.gpg.d holds a key you cannot identify, or when you are about to run a release upgrade. An unknown global key can sign for the Ubuntu archive, which is a real trust problem. If an upgrade has already gone wrong, a notice like this one is noise next to the real error, and recovering a failed Ubuntu release upgrade covers what to look at first.

You can also hide the message. apt 3.2.0 checks the option APT::Get::Update::SourceListWarnings::SignedBy, which is on by default. One config line turns it off:

echo 'APT::Get::Update::SourceListWarnings::SignedBy "false";' | sudo tee /etc/apt/apt.conf.d/99-no-signedby-notice

This changes what apt prints and nothing else. Every key in the global keyrings still signs for every source without Signed-By. Use it only after you have read those keyrings and accept what is in them.

FAQ

Is "N: Missing Signed-By" an error I have to fix?

No. N: marks a notice, which is below a warning (W:) and an error (E:). apt still updates and installs from that source. The notice means the entry has no Signed-By field, so apt accepts a signature from any key in its global keyrings. Fix it when you can, because apt has deprecated that trust model, but your server is not broken.

Why did the Missing Signed-By notice appear after I upgraded Ubuntu?

A release upgrade carries old source entries and old keys into a newer apt. apt has printed this notice for deb822 .sources entries since apt 2.7.2, and Ubuntu 24.04 ships apt 2.7.14. The public reports, one for an Ubuntu Pro ESM entry and one for a DigitalOcean mirror, both came from machines upgraded from 22.04 to 24.04.

Does apt modernize-sources fix the N: notice?

Not directly. In apt 3.2.0, apt modernize-sources converts only one-line .list files, which produce the lower A: audit message. The N: notice comes from deb822 .sources entries, so add Signed-By to those by hand. The command arrived in apt 2.9.26, which is newer than the apt 2.7.14 in Ubuntu 24.04.

Which keyring should Signed-By point at?

For a mirror of the Ubuntu archive, use /usr/share/keyrings/ubuntu-archive-keyring.gpg. For Ubuntu Pro ESM entries, use ubuntu-pro-esm-apps.gpg or ubuntu-pro-esm-infra.gpg in /usr/share/keyrings if the file exists. For a vendor repository, use a copy of the vendor key in /etc/apt/keyrings with mode 644, so the _apt user can read it. Check every file with gpg --show-keys --with-fingerprint before you reference it.