92

This is Issue 952287: [User Feedback - Stable] Reports of Chrome for Linux failing to install/update due to expired GPG signing key


Today, running apt in all my machines gives this error with the Google PPA (for google-chrome):

me@mymachine:~$ sudo apt clean && sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove -y && sudo apt autoclean -y && sudo snap refresh 
[sudo] password for me: 
Ign:1 http://dl.google.com/linux/chrome/deb stable InRelease
Hit:2 http://ppa.launchpad.net/graphics-drivers/ppa/ubuntu bionic InRelease
Hit:3 http://dl.google.com/linux/chrome/deb stable Release                     
Hit:4 http://archive.ubuntu.com/ubuntu bionic InRelease                        
Get:5 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88,7 kB]
Get:6 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74,6 kB]
Err:7 http://dl.google.com/linux/chrome/deb stable Release.gpg
  The following signatures were invalid: EXPKEYSIG 1397BC53640DB551 Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
Get:8 http://archive.ubuntu.com/ubuntu bionic-security InRelease [88,7 kB]
Get:9 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [574 kB]
Get:10 http://archive.ubuntu.com/ubuntu bionic-updates/main i386 Packages [488 kB]
Get:11 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 DEP-11 Metadata [278 kB]
Get:12 http://archive.ubuntu.com/ubuntu bionic-updates/main DEP-11 48x48 Icons [66,7 kB]
Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/main DEP-11 64x64 Icons [123 kB]
Get:14 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [756 kB]
Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/universe i386 Packages [745 kB]
Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/universe Translation-en [201 kB]
Get:17 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 DEP-11 Metadata [209 kB]
Get:18 http://archive.ubuntu.com/ubuntu bionic-updates/universe DEP-11 48x48 Icons [191 kB]
Get:19 http://archive.ubuntu.com/ubuntu bionic-updates/universe DEP-11 64x64 Icons [360 kB]
Get:20 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 DEP-11 Metadata [2.468 B]
Get:21 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 DEP-11 Metadata [7.352 B]
Get:22 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 Packages [296 kB]
Get:23 http://archive.ubuntu.com/ubuntu bionic-security/main i386 Packages [216 kB]
Get:24 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 DEP-11 Metadata [204 B]
Get:25 http://archive.ubuntu.com/ubuntu bionic-security/universe i386 Packages [127 kB]
Get:26 http://archive.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [131 kB]
Get:27 http://archive.ubuntu.com/ubuntu bionic-security/universe Translation-en [74,2 kB]
Get:28 http://archive.ubuntu.com/ubuntu bionic-security/universe amd64 DEP-11 Metadata [20,8 kB]
Get:29 http://archive.ubuntu.com/ubuntu bionic-security/universe DEP-11 48x48 Icons [12,2 kB]
Get:30 http://archive.ubuntu.com/ubuntu bionic-security/universe DEP-11 64x64 Icons [50,4 kB]
Get:31 http://archive.ubuntu.com/ubuntu bionic-security/multiverse amd64 DEP-11 Metadata [2.464 B]
Fetched 5.183 kB in 2s (2.131 kB/s)                                  
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://dl.google.com/linux/chrome/deb stable Release: The following signatures were invalid: EXPKEYSIG 1397BC53640DB551 Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg  The following signatures were invalid: EXPKEYSIG 1397BC53640DB551 Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All snaps up to date.

Already tried importing GPG key again with:

wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -

Source: Google Linux Software Repositories

EDIT: add error line in Spanish for better visibility:

Las siguientes firmas no fueron válidas: EXPKEYSIG 1397BC53640DB551 Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>

EDIT2: and French (to cover top 3 languages):

Les signatures suivantes ne sont pas valables : EXPKEYSIG 1397BC53640DB551 Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>

65

This is the protection you are getting from these checks. You don't want to update your software right now while something is messed up on Google's end. Wait until they fix it. Don't try to override by reinstalling keys until some official word comes out that a new key is the solution.

| improve this answer | |
  • 11
    Waiting until they fix it may not be an option for all. E.g. this is breaking CI pipelines for us. If you now what you are doing, you might take the risk and disable checks for this repo for now by adding [trusted=yes] to it's configuration: deb [trusted=yes] http://dl.google.com/linux/chrome/deb/ stable main – jelhan Apr 12 '19 at 8:48
  • 4
    It's not the first time this happens. I remember having this same issue with google at least 2 more times over the last years. I wonder what's going on at Google and why they can't keep their stuff together. – Michael Härtl Apr 12 '19 at 9:48
  • 4
    @jelhan That’s why CI pipelines ideally tap into local mirrors/caches rather than going directly upstream. – Konrad Rudolph Apr 12 '19 at 11:16
  • 3
    @MichaelHärtl I've been watching Google and meritocracy seems to be out of vogue. – DK Bose Apr 12 '19 at 14:02
  • 6
    trusted=yes defeats the whole purpose of digital signing and basically compromise your whole system. You should not do that lightly, especially not a good idea for a "temporary workaround". – kissgyorgy Apr 12 '19 at 16:49
33

Apparently Google did not extend the validity of the signing cert... it was due to end today and so it did. https://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0x7721F63BD38B4796

maybe Google will change it, today or so… then the update of the cert should work fine and everything should go back to normal.

| improve this answer | |
15

the problem was solved by Google Abr 12/2019 (Only Google Chrome. Tested in Ubuntu 18.04.x)

enter image description here There's nothing to do. The repository has already been signed

Update apr 19/2019:

enter image description here

Google Team has confirmed that additional fixes have gone out for other non-Chrome Google products

source: https://support.google.com/chrome/thread/4032170

| improve this answer | |
  • 3
    Where did you report that? Google still hasn't fixed it on certain other repositories, e.g. the Music Manager, so I would like to report that as well. – Paddy Landau Apr 15 '19 at 15:23
9

Looks like Google's signing keys expired. Be patient and wait for them to fix them (which may or may not require re-adding the key after they fixed it).

| improve this answer | |
1

For anyone not patient enough for google to update cert...

you can fix this with the following steps :

  1. Download this : https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

(chrome new version, you can get it yourself by googling chrome)

  1. Close Chrome.
  2. Open "Software and Sources", go to the "Sources" tab
  3. Remove (or disable if you wish to re-enable it at a later time) the Google source (type your password) and close the window
  4. Allow "Software and Sources" to reload sources
  5. Go into Software Center, go to "Installed"
  6. Find Chrome, uninstall it.
  7. Close software and sources
  8. Open a terminal, type :

    sudo apt update && sudo apt autoremove -y && sudo apt autoclean && sudo apt full-upgrade -y

  9. Close the terminal and go to your downloads folder and double click the file "google-chrome-stable_current_amd64.deb" (this will open Software Center)

  10. Click Install

you can now open chrome back up. all your tabs and saved passwords ect are still there.

| improve this answer | |
  • @CarlosAlbertoSilveiradeAnd said "Great!!, work for me! Thanks" but as an edit to my post because he doesn't know how to use this site yet.... I'm adding it so people know it worked for someone. – tatsu Apr 12 '19 at 16:31
0

You don't. You must wait for Google to renew their keys and for an update.

The important message is:

The following signatures were invalid: EXPKEYSIG 1397BC53640DB551 Google Inc. (Linux Packages Signing Authority)

It means that the cryptographic signature is invalid. The source of this can be an attack, a misconfiguration, or other kind of technical problem. Forcing your system to update will result in running an unverified version of your web browser, which can expose you to a lot of security troubles.

source

| improve this answer | |
0

Google needs to update there GPG key. You can however mark the deb source as trusted, until Google renews their key:

  1. cd /var/lib/apt/lists
  2. sudo rm \ dl.google.com_linux_chrome_deb_dists_stable_main_binary-amd64_Packages \ dl.google.com_linux_chrome_deb_dists_stable_Release \ dl.google.com_linux_chrome_deb_dists_stable_Release.gpg

  3. add trusted=yes in your /etc/apt/sources.list.d/google-chrome.list file, for it to look like this: deb [arch=amd64, trusted=yes] https://dl.google.com/linux/chrome/deb/ stable main

  4. apt clean

  5. apt update

You still get an invalid GPG error, but you can ignore it for now.

NOTE: Be careful as this may bring security issues, on non trusted networks, when no https is used in the deb source link.

EDIT: GPG warning no longer appears. Google has renewed their key. If you followed the solution above, just remove the trusted=yes part, then apt clean & finally apt update. You should no longer see any error :D

| improve this answer | |
  • 3
    Don't do this. If for no other reason than the source being unencrypted. If you did this, forgot all about it and then strayed onto a bad network, it could easily intercept and subvert the Release, packages.list, and therefore essentially run anything it liked as root on your computer. It's not a good idea. – Oli Apr 12 '19 at 12:51
  • 2
    You've missed my point. If somebody can intercept your network traffic, they can pretend to be Google. There's no TLS on a http:// connection. Normally Apt has your back here because they check that all release and package lists are signed. If you intercepted this normally —and maliciously changed something— you'd see a signing error. You're bypassing that whole mechanism here. – Oli Apr 12 '19 at 13:29
  • 1
    Indeed. Thanks for the explanation – Dimitris Moraitidis Apr 12 '19 at 13:39
  • 2
    Agreed, but you can temporarily just make it https with trusted=yes (for now, assuming you're not being TLS MiTM). For example: deb [arch=amd64, trusted=yes] https://dl.google.com/linux/chrome/deb/ stable main – link_boy Apr 12 '19 at 14:27
  • 1
    Also indeed. So I guess my recent edit, I should at least go back to 0 instead of -2 :P – Dimitris Moraitidis Apr 12 '19 at 14:33
0

Looks like, as @DooMMasteR said, Google let signing cert expire for their Linux repositories, which due date was April 12th. @yareckon explained that this apt security error is working as expected to prevent badly signed software being installed.

9 hours after the issue was posted, Google fixed certs transparently for the users using Google Chrome repo. The error stopped after they renewed the certs, progressively also on the rest of Google owned repos (Google Earth, Google Music Manager...).

No action is needed (and recommended) from users side, just waiting for the repos in use to be signed with renewed keys.

| improve this answer | |

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