Certificates issue with wget about rpi-update

[popcornmix]

Did you read the readme?
https://github.com/Hexxeh/rpi-update

[shrx]

Yes, this happened suddenly after almost a year of running this script with no problems.
I did not touch the certificates for some time now, so the issue must be elsewhere.
Also the time is synchronised.
edit: also, if I run the script with UPDATE_SELF=0, it works.

[popcornmix]

Does
wget https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
work? (it does currently for me)

Can you wget from any https page?

[skgsergio]

Running with UPDATE_SELF=0 don't trigger wget that's why it works. On the other hand, is not the date problem @popcornmix have a look to this:

ERROR: certificate common name *.a.ssl.fastly.net'** doesn't match requested host name **raw.github.com'.

I saw, the cdn that GitHub uses is fastly and for some unknown reason couldn't identify the domain you were accessing (raw.github.com) so the server gave you the fastly generic ssl certificate causing wget fail because is not the site it asked for... Why the server is not identifying what domain is your wget is asking for? I don't know... can be a proxy forwarding bad info, can be a temporal issue, can be a bug on wget... don't really know...

If you don't have proxys I think that the issue will disappear like it appeared...

[shrx]

@popcornmix I get the same error with your suggested command.
Downloading an image from https wikipedia works:

wget https://upload.wikimedia.org/wikipedia/commons/thumb/3/32/Koningin_Beatrix_in_Vries.jpg/100px-Koningin_Beatrix_in_Vries.jpg
--2013-01-28 22:45:45--  https://upload.wikimedia.org/wikipedia/commons/thumb/3/32/Koningin_Beatrix_in_Vries.jpg/100px-Koningin_Beatrix_in_Vries.jpg
Resolving upload.wikimedia.org... 91.198.174.234, 2620:0:862:ed1a::b
Connecting to upload.wikimedia.org|91.198.174.234|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9016 (8.8K) [image/jpeg]
Saving to: `100px-Koningin_Beatrix_in_Vries.jpg'

100%[======================================>] 9,016       --.-K/s   in 0.002s  

2013-01-28  22:45:45 (5.52 MB/s) - `100px-Koningin_Beatrix_in_Vries.jpg' saved [9016/9016]

I don't use a proxy.

[skgsergio]

Very funny, really... Have a look to this:

The failed download is from my dedicated server hosted by OVH at France. The successful download is from my work at Spain (Technical University of Madrid - RedIRIS network)... Also form my house works without problems...

So is not your issue, seems that GitHub's CDN it's failing...

[shrx]

Interesting. So I should just wait till they fix it.

[licaon-kter]

I had some issues a few days ago too, not certificate related ( Hexxeh/rpi-firmware#7 ) but mostly pointing out that github itself seems at fault.

[popcornmix]

Is this working again?

[shrx]

No, still the same error.

[shrx]

Update:

On the left is my main raspberry pi with the non-working script. On the right is the secondary raspberry pi - the script works. Both are connected to the internet through the same router.
The difference between them is that the non-working script is on the soft-float debian, the working is on hard-float.
Could this be the problem?

[metachris]

To solve this issue, you could just add --no-check-certificate as parameter for wget. I believe the security risk by not checking the certs is neglectible since we know the link refers to the correct filename and just assume Github has not been hacked.

[shrx]

Another update:
I spent several hours building the latest version of wget (1.14) and its dependencies, but it was worth it. The newly built version works with no errors.

[popcornmix]

So do you believe it is a bug in older version of wget?
May be worth flagging the issue on raspbian section of forum for plugwash to consider updating.

[skgsergio]

After digging the internet I saw that wget debian packages prior to 1.14-1 don't have SNI [1] support so the webserver don't know which ssl certificate needs to use.

I've checked and my failing machine has 1.12 and the working machine 1.14 :)

For more info: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653267

[1] http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

[shrx]

I've also received reply from github support:

This is a bug in older versions of wget where it does not correctly parse the full list of subjectAlternateNames in the certificate. If you open the cert, you will see that raw.github.com is listed, but it's rather far down on the list. The only recommendation I have at this time is to try a more recent version of wget, or consider switching to cURL.

So someone should put the 1.14 version of wget on apt-get repositories for the old soft-float debian, so people could update it easily without compiling everything.
I don't know how to do it, but I can upload the compiled files if it helps. (I'd need to know which files need to be uploaded too.)

[popcornmix]

So someone should put the 1.14 version of wget on apt-get repositories for the old soft-float debian, so people could update it easily without compiling everything.

The soft float debian should be the standard debian wheezy packages. Have you run
sudo apt-get update && sudo apt-get upgrade
?

[metachris]

Good job on finding the root cause. Currently the standard wget version in the wheezy repos is 1.12 (http://packages.debian.org/stable/wget). A quick fix for the meantime could be to add --no-check-certificate as parameter for wget in the rpi-update.sh script.

[popcornmix]

wheezy is not stable though:
http://packages.debian.org/wheezy/wget
shows wget at 1.13.4-3.

Which is newer than my Ubuntu 11.10 machine...

[metachris]

Good point, I used the wrong link (first result habit on Google). Here's the overview: http://packages.debian.org/search?keywords=wget

[shrx]

This is the debian I have:

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 6.0.6 (squeeze)
Release: 6.0.6
Codename: squeeze

[popcornmix]

@shrx
That is very old. There is a soft float version of wheezy available for download if you need soft float (although hard float would be recommened).

[shrx]

Yeah, I got my raspberry pi in may 2012, and wheezy came out much later, when I already got my entire system set up and running. So I decided to not upgrade and deal with everything again. And afaik I can't just use wheezy packages on squeeze?

[Pitel]

I just got this errors, wget https://github.com/Hexxeh/rpi-update/raw/master/rpi-update doesn't work. It worked fine couple of days ago.

--2014-03-20 09:06:47--  https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
Resolving github.com (github.com)... 192.30.252.131
Connecting to github.com (github.com)|192.30.252.131|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update [following]
--2014-03-20 09:06:52--  https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.31.17.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.17.133|:443... connected.
GnuTLS: A TLS warning alert has been received.
Unable to establish SSL connection.

GNU Wget 1.13.4 built on linux-gnueabihf.

+digest +https +ipv6 +iri +large-file +nls -ntlm +opie +ssl/gnutls 

Wgetrc: 
    /etc/wgetrc (system)
Locale: /usr/share/locale 
Compile: gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc" 
    -DLOCALEDIR="/usr/share/locale" -I. -I../lib -I../lib 
    -D_FORTIFY_SOURCE=2 -Iyes/include -g -O2 -fstack-protector 
    --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
    -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall 
Link: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
    -Werror=format-security -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall 
    -Wl,-z,relro -Lyes/lib -lgnutls -lgcrypt -lgpg-error -lz -lidn -lrt 
    ftp-opie.o gnutls.o ../lib/libgnu.a 

Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic <[email protected]>.
Please send bug reports and questions to <[email protected]>.

[popcornmix]

It is working for me at the moment:

pi@raspberrypi:~ $ wget https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
--2014-03-20 14:49:59--  https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
Resolving github.com (github.com)... 192.30.252.129
Connecting to github.com (github.com)|192.30.252.129|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update [following]
--2014-03-20 14:50:05--  https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.31.16.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.16.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7174 (7.0K) [text/plain]
Saving to: `rpi-update'

100%[==========================================================================================================================================================================================================================================================================>] 7,174       --.-K/s   in 0.009s  

2014-03-20 14:50:09 (789 KB/s) - `rpi-update' saved [7174/7174]

Not sure if it was a temporary glitch (I did notice that github web interface was very slow yesterday, but seems better today), or it's something location dependent. Can you try again now?

[Pitel]

It still doesn't work.

I'm from Czech Republic, and github.com resolved to 192.30.252.131 and raw.githubusercontent.com resolved to 185.31.17.133.

[notGMman]

Exactly the same error for me. The redirection resolved first to 185.31.17.133 and then to 185.31.16.133 and neither worked. Tried on two raspis, both at the end of the upgrade process so already up-to-date software. wget version 1.13.4. Not a firewall issue - I can see the traffic tootling off over the www just fine.

[notGMman]

Ah, from the posts on the Troubleshooting forum at http://www.raspberrypi.org a lot of people are seeing the same fault.

[notGMman]

OK, on an old raspi, not up-to-date software but same wget version, the self update works just fine. Looks like something has happened in a piece of code we pick up elsewhere.

[popcornmix]

pi@raspberrypi:~ $ wget --version
GNU Wget 1.13.4 built on linux-gnueabihf.

So wget 1.13.4 is working for me.

Does changing /etc/resolv.conf to include:
nameserver 8.8.8.8

make any difference?

[notGMman]

the google nameserver is already the only resolver in the file

[notGMman]

A quick google suggests this isn't only a raspi issue. One or two other posts in the last day or two from debian users - eg. something called calibre.
And a report on "theregister" about GnuTLS here: http://www.theregister.co.uk/2014/03/05/gnu_security_library_gnutls_fails_on_cert_checks_patch_now/

[g7ruh]

I tried this several hours ago and posted on troubleshooting on raspi forum. It is still the same now

[skgsergio]

As I said one year ago here #65 (comment) the problem is that wget prior to 1.14 doesn't have SNI extension and GitHub uses it so it sometimes fail. Once you update to wget 1.14 or greater it works.

@notGMman the gnutls fail isn't related to your issue. It's a complete different thing.

[notGMman]

OK skgsergio. There's not much detail in these comments which is why I didn't google "wget sni" before. Sad to see a bug fix proposed for wget 1.11 not incorporated in 1.13 and also sad that rp-update fails without it, as you put it "sometimes". Thanks for the info anyway.
Got mine to work by copying rpi-update to rpi-update.tmp and then deleting the wget self update from the original script before running it.

[skgsergio]

@notGMman instead editing rpi-update you can just run UPDATE_SELF=0 rpi-update if it fails self-updating it.

[skgsergio]

Ok, I've checked and debian backported the fix to wget 1.13.4 (http://metadata.ftp-master.debian.org/changelogs/main/w/wget/wget_1.13.4-3+deb7u1_changelog) and plugwash confirmed me that it is already in Raspbian:

<plugwash> repo@raspbian:~/private/private$ reprepro list wheezy wget
<plugwash> wheezy|main|armhf: wget 1.13.4-3+deb7u1

So please run apt-get update && apt-get upgrade and then try rpi-update.

@popcornmix If the ppl having this problem update the system shouldn't have this issue.

[peepo]

~ $ wget -V
GNU Wget 1.13.4 built on linux-gnueabihf.

I already ran sudo update upgrade

nix for rpi-update as per above, and yes ca certificates is installed and time checked...

updates appreciated....

[notGMman]

Hi skgsergio - that's quick work. But I tried the apt-get upgrade and it picked up no changes. So I removed and then installed wget and rpi-update still hasn't worked. Didn't do a reboot between remove and install though - just rebooted before the rpi-update.

[jj358mhz]

I am running into the same issue as well. I did all recommended updates/upgrades and am still receiving the ca-certificates error.

[MrEngman]

I am seeing an error a well. All was OK until I installed the newest version of wget.

Unpacking wget (from .../wget_1.13.4-3+deb7u1_armhf.deb) ...

wget -V
GNU Wget 1.13.4 built on linux-gnueabihf.

Then now I receive the following error

Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.18.133|:443... connected.
GnuTLS: A TLS warning alert has been received.
Unable to establish SSL connection.
 !!! Failed to download update for rpi-update!
 !!! Make sure you have ca-certificates installed and that the time is set correctly

ca-certificates and time are OK

Installed new image raspbian 3.10.25+ #622 then updated using rpi-update to 3.10.33+ #658 and rpi-update ran OK. Using apt-get update/upgrade and installing all files ~20 excluding wget and rpi-update still OK. After installing wget then rpi-update failed on self-update.

Also installing new image raspbian 3.10.25+ then updated using rpi-update to 3.10.33+ #658 and only installing wget 1.13.4 and none of the other packages indicated by apt-get upgrade and rpi-update again failed on self-update as above.

[dl9sec]

Seems for me, that it doesn't work anymore since kernel 3.10.33+ #654...

[skgsergio]

Weird... The patch Debian included in wget 1.13.4-3+deb7u1 should fix it but the problem seems to be even worst. With wget 1.14 I've run 500 downloads from github without problem, so if Debian backported the patch correctly it should work... I'm going to do some test to see if I can understand what's happening now.

Let's see if I can get a proper workaround.

I can confirm the bug:

root@rpi:/# apt-cache policy wget | grep Installed
  Installed: 1.13.4-3+deb7u1
root@rpi:/# wget https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
--2014-03-21 08:57:51--  https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
Resolving github.com (github.com)... 192.30.252.128
Connecting to github.com (github.com)|192.30.252.128|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update [following]
--2014-03-21 08:58:01--  https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.31.18.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.18.133|:443... connected.
GnuTLS: A TLS warning alert has been received.
Unable to establish SSL connection.

[mwagner]

As workaround I downloaded the rpi-update script manually and run with UPDATE_SELF=0:

curl -O https://raw.githubusercontent.com/Hexxeh/rpi-update/master/rpi-update
chmod +x rpi-update
sudo UPDATE_SELF=0 ./rpi-update

[skgsergio]

Well, the problem here has changed... there is no SNI problem now. I've done multiple tests about SNI without problems.

I'll try to be as plain as I can with the thing I think is the problem:

Since Feb 25 00:00:00 2014 GMT GitHub is using a new certificate which wget/GnuTLS don't likes. How can be that?

New certificate subject is:
C=US, ST=California, L=San Francisco, O=Fastly, Inc., CN=www.github.com
That is valid for www.github.com.

But also it have this extension:

X509v3 Subject Alternative Name: 
    DNS:www.github.com, DNS:*.github.com, DNS:*.github.io, DNS:*.githubusercontent.com

So it's also valid for raw.githubusercontent.com but seems that wget/GnuTLS is not checking the alternative name extension...

What can we do? If the reference images comes with curl we can simply switch to curl: curl https://url/.. -o /path/to/store/the/file. If is not installed we can simply warn the user to install it (just checking if curl exists).

[popcornmix]

Strangely rpi-update is still working just fine for me. I've run it multiple times, and can wget from github both on Pi and Ubuntu.
But, I've pushed a commit to use curl rather than wget. Any better?

[skgsergio]

@popcornmix seems to be a little random because sometimes fails and sometimes works for me on the RPi. On Ubuntu you probably have a greater version like me on Debian or Arch.

[mwagner]

after getting the updated file using curl it works fine

[popcornmix]

So, to get from the current rpi-update to the latest rpi-update you should be able to run:

sudo curl -L --output `which rpi-update` https://github.com/Hexxeh/rpi-update/raw/master/rpi-update

[iz8mbw]

Hi.
With: "sudo curl -L --output which rpi-update https://github.com/Hexxeh/rpi-update/raw/master/rpi-update"
it works:
root@raspberrypi:~# sudo curl -L --output which rpi-update https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 135 100 135 0 0 214 0 --:--:-- --:--:-- --:--:-- 283
100 7177 100 7177 0 0 6951 0 0:00:01 0:00:01 --:--:-- 38586

root@raspberrypi:~# rpi-update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
*** Performing self-update
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 135 100 135 0 0 193 0 --:--:-- --:--:-- --:--:-- 253
100 7177 100 7177 0 0 7787 0 --:--:-- --:--:-- --:--:-- 7787
*** Relaunching after update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
*** ARM/GPU split is now defined in /boot/config.txt using the gpu_mem option!
*** Setting up firmware (this may take a few minutes)
Cloning into '//root/.rpi-firmware'...

[g7ruh]

Thanks popcornmix your post above to get from current to latest works fine on the two pis on which it failed yesterday

[shrx]

Github interprets "`" tags as markdown, the alternative non-ambiguous command is

sudo curl -L --output $(which rpi-update) https://github.com/Hexxeh/rpi-update/raw/master/rpi-update

[StormTrooper]

sudo curl -L --output `which rpi-update` https://github.com/Hexxeh/rpi-update/raw/master/rpi-update

Works great for me thanks,

[beta-tester]

@popcornmix : said: "Strangely rpi-update is still working just fine for me. I've run it multiple times, and can wget from github both on Pi and Ubuntu."
are you sure, you ran "sudo apt-get -y dist-upgrade" these days, that installed the new "wget" package to RPi?
i have more than one RPi and all run "sudo rpi-update" fine until i run dist-upgrade. just after that all tries to run rpi-update (the wget version) failed.

-using fresh wheezy image, then dist-upgrade, then rpi-update => will fai.l

-using fresh wheezy image, then rpi-update then dist-upgrade => works fine.
(following rpi-update will fail, because of upgraded wget package)

EDIT 2014-03-27 08:30:
i just saw, via dist-upgrade two new packages will be upgraded that maybe will fit wget problems
libssl 1.0.1e-2+rvt+deb7u4
openssl 1.0.1e-2+rvt+deb7u4

[asb]

I've updated the rpi-update debian package. You can sudo apt-get update && sudo apt-get install rpi-update to get the curl-based rpi-update package (or just replace it using one of the commands above).

[bast69]

It's works fine for me !
Why this issue isn't close ?

[jicho]

The solution from @asb did the trick for me :)

[popcornmix]

@shrx okay to close?

[Klendat]

I am experiencing the same issues in this thread. This issue is most definitely not closed.

If I do

apt-get install rpi-update 

It just says it can't find rpi-update

If I try:
wget https://github.com/Hexxeh/rpi-update/raw/master/rpi-update --no-check-certificate

the script downloads but if I try to run it the whole thing fails.

I don't know how to add --no-check-certificate to the script. I tried in the URL but it failed.

I'm just trying to get my rpi up and running because I got my pi from the store with an SD card that was carrying a raspbian version that causes a kernel panic when I plug in a wired keyboard. rpi-update should fix that but it doesn't work.

These are my first steps into Linux and it's like a nightmare so far. Everything I try is like a beartrap.

[popcornmix]

The correct command is:
sudo apt-get update && sudo apt-get install rpi-update

If that doesn't work might be worth installing an official image from here:
http://www.raspberrypi.org/downloads/

You can also manually install it with:
sudo curl -L --output /usr/bin/rpi-update https://raw.github.com/Hexxeh/rpi-update/master/rpi-update && sudo chmod +x /usr/bin/rpi-update

[Klendat]

This is an official raspbian release but it just needs to be updated. I didn't buy this at the corner shop I bought it at RS Components.

when I try the first one some updates come through but the rest is

E: Some index files failed to download, they have been ignored, or old ones used instead.

When I try the curl command I just get

#sudo: curl: command not found

[asb]

This really needs to be taken to the forums. curl has been included on the Foundation's Raspbian image since June 2012. What does your /etc/rpi-issue say?

[Klendat]

Apparently my starter pack was older.

uname -a says

Linux raspberrypi 3.1.9+ #90 Wed Apr 18 18:23:05 BST 2012 armv6l GNU/Linux

[asb]

That's ancient. You didn't buy it recently did you? I strongly, strongly recommend you download a new image and reflash your SD card.

[Klendat]

I bought last year but I only got around to using it now. I dread flashing my card because I only have windows machines and I hear that can cause some problems too.

[lurch]

As long as you follow the official instructions you should be fine. Even using Windows :-)

[Ruffio]

It looks like this issue has been resolved and can therefore be closed.