While updating my packages on a debian based system by a

sudo apt-get update

I've got that error message :

Reading package lists... Done
W: GPG error: ftp://ftp.fr.debian.org stable/non-US Release: 
The following signatures were invalid: KEYEXPIRED 1138684904

What should I do to fix this ?


To find any expired repository keys and their IDs, use apt-key as follows:

LANG=C apt-key list | grep expired

You will get a result similar to the following:

pub   4096R/BE1DB1F1 2011-03-29 [expired: 2014-03-28]

The key ID is the bit after the / i.e. BE1DB1F1 in this case.

To update the key, run

sudo apt-key adv --recv-keys --keyserver keys.gnupg.net BE1DB1F1

Note: Updating the key will obviously not work if the package maintainer has not (yet) uploaded a new key. In that case there is little you can do other than contacting the maintainer, filing a bug against your distribution etc.

One liner to update all expired keys: (thanks to @ryanpcmcquen)

for K in $(apt-key list | grep expired | cut -d'/' -f2 | cut -d' ' -f1); do sudo apt-key adv --recv-keys --keyserver keys.gnupg.net $K; done
  • 4
    that does not work for me, after the command for updating the key, the key is still expired. – Karl Forner Nov 6 '14 at 12:20
  • @KarlForner was adding the key successful? – kynan Nov 7 '14 at 10:18
  • yes it was successful. – Karl Forner Nov 7 '14 at 14:08
  • 4
    One liner: for K in $(apt-key list | grep expired | cut -d'/' -f2 | cut -d' ' -f1); do sudo apt-key adv --recv-keys --keyserver keys.gnupg.net $K; done – ryanpcmcquen Dec 11 '16 at 0:47
  • 2
    Just a hint as to grep part: "expired" is i18ned, so depending on LANG* settings this may not work, for instance for settings pl_PL.UTF-8 one has to change "expired" to "wygasł" to make this one-liner to work. – Cromax Apr 25 '17 at 16:30

You need to get the newer key and add it, at which point apt will detect it and not complain. This shouldn't normally happen, but it sometimes does. What you really need is to know the hex code of the key you need to add; once you have that, it's pretty much downhill from there.

Some examples:


On the Debian Wiki about SecureAPT, I've found that I should remove the line containing non-us from /etc/apt/sources.list.

I actually did that and it worked.

  • 5
    This may have worked in one particular case but is not a generic solution – kynan Nov 4 '15 at 20:52

I had similar error, but problem was in system time. The year was 1961 :)

I corrected system date/time and after that could update without a pro


It might also happen when the date is not correct.

Check the date with


If it's misconfigured, do the following to set your timezone and date auto synchronization.

apt-get install ntp ntpdate && service ntp stop
dpkg-reconfigure tzdata
service ntp start

A more simple oneliner:

for key in $(sudo apt-key list | awk -v FS='[ /:]+' '/expire[sd]/ {print $3}'); do sudo apt-key adv --recv-keys --keyserver keys.gnupg.net $key; done

I just feel that if you are doing things like using cut more than once, there is a better tool. (Also, I created this based on a different question.)


One highly unlikely, but occasionally possible, cause for this error is if having added the same key twice with different expiry dates. You would likely know having done so for this answer to be relevant to you.

This can happen, as it did for me, when hosting your own repository with your own keys. If you, when the key is about to expire, simply extend its lifetime rather than change it, and if you installed the original key using preseeding but the updated key using a deb package, then the old key will be in /etc/apt/trusted.gpg, while the new one ends up as a separate file under /etc/apt/trusted.gpg.d/. The old key will shadow the new one, which will be completely ignored by apt-key. Remove the old key by running gpg --keyring /etc/apt/trusted.gpg --delete-keys <keyid>, and your new key will become detected.

This is a bit of a non-standard corner configuration, but I hope my answer can save some confusion in case anyone else encounters this issue due to the same reason as I did.


You don't have to do anything. It is just a warning, you can see that from the W: prefix.

  • 1
    If he didn't have to do anything the whole Signing system for Repos would be useless. This is a security feature and in production envirionments key integrity is crucial for security. – Broco Mar 15 '18 at 17:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.