What should I do when I got the KEYEXPIRED error message after an apt-get update?

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

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:

• adding keys for backports: the first few lines are what you're after, although you'll need to have the key it wants.

• adding keys ala Ubuntu

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.

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

date

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
ntpdate-debian
service ntp start

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.

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.)

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