Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.
Sign up to join this community
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 YOUR_GPGKEY_HOST_DOMAIN BE1DB1F1
Note:
YOUR_GPGKEY_HOST_DOMAIN indicates domain name of any available GPG key server, such as
keyserver.ubuntu.comkeys.openpgp.orgpgp.mit.edukeys.gnupg.net is deprecated and gone.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
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
Dec 11, 2016 at 0:47
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.
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
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
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.
