Distributions: Error gnutls_handshake() failed: Handshake failed on debian
Hello,
Today, apt-get update is failing with this error on my computer debian:
W: impossible de r茅cup茅rer https://deb.nodesource.com/node_4.x/dists/jessie/main/binary-amd64/Packages聽: gnutls_handshake() failed: Handshake failed
E: 脡chec du t茅l茅chargement pour certains fichiers d'index. Soit ils ont 茅t茅 ignor茅s, soit les anciens fichiers ont 茅t茅 utilis茅s 脿 la place.
E: Impossible de reconstruire le cache des paquets
Yesterday it worked, the issue seem to have appeared just a few hour ago. Any idea?
ghusse
All 51 comments
Can confirm this, steps to reproduce:
curl --silent https://deb.nodesource.com/gpgkey/nodesource.gpg.key | sudo apt-key add -
add-apt-repository 'deb https://deb.nodesource.com/node_5.x main trusty main'
sudo apt-get update
Error string:
gn http://ap-south-1.ec2.archive.ubuntu.com trusty/multiverse Translation-en_US
Ign http://ap-south-1.ec2.archive.ubuntu.com trusty/restricted Translation-en_US
Ign http://ap-south-1.ec2.archive.ubuntu.com trusty/universe Translation-en_US
Fetched 2,888 kB in 10s (279 kB/s)
W: Failed to fetch https://deb.nodesource.com/node_5.x/dists/main/trusty/binary-amd64/Packages gnutls_handshake() failed: Handshake failed
W: Failed to fetch https://deb.nodesource.com/node_5.x/dists/main/main/binary-amd64/Packages gnutls_handshake() failed: Handshake failed
E: Some index files failed to download. They have been ignored, or old ones used instead.
Happening with 6_x version too
W: Failed to fetch https://deb.nodesource.com/node_6.x/dists/main/trusty/binary-amd64/Packages gnutls_handshake() failed: Handshake failed
W: Failed to fetch https://deb.nodesource.com/node_6.x/dists/main/main/binary-amd64/Packages gnutls_handshake() failed: Handshake failed
E: Some index files failed to download. They have been ignored, or old ones used instead.
Hashfyre
on 16 Nov 2016
The TLS error:
gnutls-cli -V -p 443 deb.nodesource.com
Processed 174 CA certificate(s).
Resolving 'deb.nodesource.com'...
Connecting to '54.230.79.150:443'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed
*** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.
I can confirm that this error as well. Was going to install it in a Docker installation and it worked until an hour earlier (~GMT 08:00).
Could be some server issues?
netsgnut
on 16 Nov 2016
% openssl s_client -connect deb.nodesource.com:443
CONNECTED(00000003)
140736615212040:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:
bradleythughes
on 16 Nov 2016
Seeing that Nodesource uses Cloudfront, I used this command to check the cipher. Reference here.
$ openssl s_client -ssl3 -tls1 -cipher 'ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA AES256-SHA AES128-SHA DES-CBC3-SHA RC4-MD5' -connect deb.nodesource.com:443
CONNECTED(00000003)
139908810094240:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1263:SSL alert number 40
139908810094240:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:599:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1479286901
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
It appears that deb.nodesource.com has started requiring SNI. I can successfully connect with openssl s_client by specifying the servername:
% openssl s_client -servername deb.nodesource.com -connect deb.nodesource.com:443
CONNECTED(00000003)
depth=4 C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
verify return:1
depth=3 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
verify return:1
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = *.nodesource.com
verify return:1
---
Certificate chain
0 s:/CN=*.nodesource.com
i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
i:/C=US/O=Amazon/CN=Amazon Root CA 1
2 s:/C=US/O=Amazon/CN=Amazon Root CA 1
i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEVDCCAzygAwIBAgIQA1v+FvBs48EofJbcTb5dQDANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRUwEwYDVQQLEwxTZXJ2ZXIg
Q0EgMUIxDzANBgNVBAMTBkFtYXpvbjAeFw0xNjA5MDYwMDAwMDBaFw0xNzEwMDYx
MjAwMDBaMBsxGTAXBgNVBAMMECoubm9kZXNvdXJjZS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCC/cO8zKBo6S81z0o8ep9k3QioxRCKh8Dw/Amn
dUQx6VAC7x6yEirxF3KPQNNmzMS/k6c++4rr7kpmhaUSqvXegi+069OB6yGbPwdO
5HNKUeZ4YeEaZ3F+CHHOQ8zV4QaGAXHXfmjHZdso1ukHjfpAVKKiTCKfev9I51Nc
iKjJuiIGFVXpsoQdB7v+/rrbCZD4qvdso1CeLVHdQHPYwPGwcV1v4eS6UlosV9iy
93Z4/NhJ2A1vF/ahWgTlsWUeclfl2CSZLA7jz19It5wBx8NzeYPH79AtD5FEJ2C0
2NFJBr1wiV6rQE3UUhjCWVN/lk02E+4jOxp+Ru/0dtkMavtnAgMBAAGjggFnMIIB
YzAfBgNVHSMEGDAWgBRZpGYGUqB7lZI8o5QHJ5Z0W/k90DAdBgNVHQ4EFgQUOeqb
mSRG6Lzpm7nS2sOrb+qlPqcwGwYDVR0RBBQwEoIQKi5ub2Rlc291cmNlLmNvbTAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMDsG
A1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9jcmwuc2NhMWIuYW1hem9udHJ1c3QuY29t
L3NjYTFiLmNybDATBgNVHSAEDDAKMAgGBmeBDAECATB1BggrBgEFBQcBAQRpMGcw
LQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnNjYTFiLmFtYXpvbnRydXN0LmNvbTA2
BggrBgEFBQcwAoYqaHR0cDovL2NydC5zY2ExYi5hbWF6b250cnVzdC5jb20vc2Nh
MWIuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADggEBAKmvXHkXZn37
FCO6rGc99t9MQPjeVwgLcU0bitO0gwrhduzmhuYzmuoNPcBsqyf3bN8Tip32IjM1
sS5LmdDVE/pfQUKBDmdmrTxP4NsBmdyMnMh508qd51uyXo5JmzAhj8LmN1F+KIAP
ks9WbNsaUThqQmIwjegDXz8b9nRj7Z22z/ATx+vbz4H6RCxjZ3cONPUiIDrF6qU1
34NJc7mRZu5dkHYhcz3kiuJO7l3gkG/DfstFppackWiihIScbTQikZngjtNvKQZc
OECbPJD+31nfK0013k7y+03bT+wY3qOAXWyHlFnDtEQ9jeVm/bNW9AjbcnGfvWwb
aORQXnmN5Y8=
-----END CERTIFICATE-----
subject=/CN=*.nodesource.com
issuer=/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5215 bytes and written 461 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: ...
Session-ID-ctx:
Master-Key: ...
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 10800 (seconds)
TLS session ticket:
...
Start Time: 1479287736
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
GNU TLS handles SNI, so I don't think apt-transport-https failure is linked to SNI.
According to the server supported ciphers (extracted with NMAP), I don't see any intersection with gnutls supported ciphes on Debian 8 (Jessie, stable).
$ nmap --script ssl-enum-ciphers deb.nodesource.com
Same list extracted from Qualys' SSL Labs : https://www.ssllabs.com/ssltest/analyze.html?d=deb.nodesource.com&s=52.84.213.14&hideResults=on
$gnutls-cli -l
Both show similar ciphers, but the one from deb.nodesource.com include a WITH keyword, which is missing from GNU TLS ciphers list, here is an example using TLS1.0 ciphers:
Nodesource:
TLSv1.0:
ciphers:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
TLS_RSA_WITH_AES_128_CBC_SHA - strong
TLS_RSA_WITH_AES_256_CBC_SHA - strong
compressors:
NULL
From gnutls-cli -l
TLS_ECDHE_RSA_AES_128_GCM_SHA256 0xc0, 0x2f TLS1.2
TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2
TLS_RSA_AES_128_GCM_SHA256 0x00, 0x9c TLS1.2
TLS_RSA_AES_256_GCM_SHA384 0x00, 0x9d TLS1.2
It seems to me the issue is coming from CloudFront
fulax
on 16 Nov 2016
I can confirm this on a fresh ubuntu/trusty64 box using vagrant
shrmrf
on 16 Nov 2016
There's an issue with the docker project too.. https://github.com/docker/docker/issues/16941#issuecomment-260912326
52.222.171.* might be bad??
$ dig deb.nodesource.com
; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> deb.nodesource.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9462
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;deb.nodesource.com. IN A
;; ANSWER SECTION:
deb.nodesource.com. 299 IN CNAME d2buw04m05mirl.cloudfront.net.
d2buw04m05mirl.cloudfront.net. 59 IN A 52.222.171.152
d2buw04m05mirl.cloudfront.net. 59 IN A 52.222.171.12
d2buw04m05mirl.cloudfront.net. 59 IN A 52.222.171.174
d2buw04m05mirl.cloudfront.net. 59 IN A 52.222.171.90
d2buw04m05mirl.cloudfront.net. 59 IN A 52.222.171.105
d2buw04m05mirl.cloudfront.net. 59 IN A 52.222.171.113
d2buw04m05mirl.cloudfront.net. 59 IN A 52.222.171.102
d2buw04m05mirl.cloudfront.net. 59 IN A 52.222.171.144
;; Query time: 56 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Wed Nov 16 10:39:21 UTC 2016
;; MSG SIZE rcvd: 218
My Docker build and nodesource failed same time :(
thuandt
on 16 Nov 2016
Workaround for now:
change
deb https://deb.nodesource.com/node_5.x $distribution main
to
deb https://d2buw04m05mirl.cloudfront.net/node_5.x $distribution main
(It's the same server but the SSL handshake will suceed - apt doesn't need to know about SNI in this case.)
steinex
on 16 Nov 2016
Any workaround to get the installation script working for now?
tomashora
on 16 Nov 2016
@thuandt @steinex I managed to get the installations working (both docker and nodesource) by changing https to http in the nodesource.node Ansible repo e.g. in the following line, just remove the s from https... also from all other links...
https://github.com/nodesource/ansible-nodejs-role/blob/master/tasks/main.yml#L22
shrmrf
on 16 Nov 2016
@shrmrf But you are opening up the packages to tampering by MiTM.
Hashfyre
on 16 Nov 2016
@Hashfyre Some people dont really have a choice right now.
I fixed it by doing.. :
curl -sL https://d2buw04m05mirl.cloudfront.net/setup_6.x | sed "s/deb.nodesource.com/d2buw04m05mirl.cloudfront.net/" | sed "s/\(deb\(-src\)\? http\)s/\1/" | sudo -E bash -
It downloads the original install script, then uses cloudfront's domain with HTTP instead of HTTPS. I'll do that until they fix it probably tomorrow.
Esya
on 16 Nov 2016
@Esya It's doesn't work on ubuntu 14.04
omeraplak
on 16 Nov 2016
@omeraplak What issue do you encounter with that solution?
Esya
on 16 Nov 2016
@Esya same problem
Fetch Fail
gnutls_handshake() failed: Handshake failed
sqlProvider
on 16 Nov 2016
Same problem, looks like the fetch for this is throwing a 404:
W: Failed to fetch https://deb.nodesource.com/node_6.x/dists/precise/main/source/Sources gnutls_handshake() failed: A TLS fatal alert has been received.
ibrennan
on 16 Nov 2016
@Hashfyre yes... that's why I'm not deploying today.... Skipped the deployment for today and will do it on Friday ;)
NOBODY should be doing this in production or on their systems. Try these things inside a VM...
Of course I can change the servers etc. but mehhh, this should get fixed soon, there's no fire... everything's okay... http://weknowmemes.com/wp-content/uploads/2014/09/this-is-fine-meme.jpg
shrmrf
on 16 Nov 2016
@omeraplak @sqlProvider @ibrennan The issue is that you still have the old source files.
Please run first :
sudo rm /etc/apt/sources.list.d/node.js.list /etc/apt/sources.list.d/nodesource.list
Then
curl -sL https://d2buw04m05mirl.cloudfront.net/setup_6.x | sed "s/deb.nodesource.com/d2buw04m05mirl.cloudfront.net/" | sed "s/\(deb\(-src\)\? http\)s/\1/" | sudo -E bash -
Please confirm if this workaround does it for you. (Edit: As someone said before, this is a dirty temporary solution. When this is fixed upstream, please go back to using HTTPS for your packages)
Esya
on 16 Nov 2016
@Esya
It's work! Thank you
omeraplak
on 16 Nov 2016
I'm currently on Debian Jessie and receiving the same problem.
@shrmrf If you change to HTTP, the packages are still checked against the GPG signatures so it will fail installation if tampered with en route. I'm pretty sure the signatures are checked before dpkg is invoked. (though better to be safe than sorry with production systems).
The GPG keys still install fine over HTTPS via curl, so this seems to be associated with apt https method. Though it's a pretty sweeping change to just apply "SSL" mandates without any testing on LTS Distros.
zoltrain
on 16 Nov 2016
@Esya you are a man bro, thanks.
sqlProvider
on 16 Nov 2016
@zoltrain yeah, I agree.
shrmrf
on 16 Nov 2016
This can be replicated but just building fresh AWS Ubuntu 14.04 which today will give you "Ubuntu 14.04.5 LTS".
The fix suggested by @Esya produces the following file for version 4.
$ cat /etc/apt/sources.list.d/nodesource.list
deb http://d2buw04m05mirl.cloudfront.net/node_4.x trusty main
deb-src http://d2buw04m05mirl.cloudfront.net/node_4.x trusty main
$
The following might work as well.
$ cat /etc/apt/sources.list.d/nodesource.list
deb http://deb.nodesource.com/node_4.x trusty main
deb-src http://deb.nodesource.com/node_4.x trusty main
$
marcinrozanski
on 16 Nov 2016
As of October 26th Debian Jessie nodes with libgnutls-deb0-28=3.3.8-6+deb8u3 (The latest version) were able to download from Nodesource - but now can't. 3.3.8-6+deb8u2 also fails.
So, since that date, either:
(1) Nodesource have moved to Cloudfront, or...
(2) AWS Cloudfront have changed something in SSL.
I'm looking into the exact failure, but I suspect a non-HTTP workaround will prove difficult if it's a Cloudfront problem.
zoeimogen
on 16 Nov 2016
Here's an easy command to reproduce this issue:
docker run --rm -it debian:stable sh -c "apt-get update; apt-get install -y wget; GNUTLS_DEBUG_LEVEL=7 wget https://deb.nodesource.com"
gnutls[2]: Enabled GnuTLS logging...
gnutls[2]: Intel SSSE3 was detected
gnutls[2]: Intel AES accelerator was detected
gnutls[2]: Intel GCM accelerator was detected
converted 'https://deb.nodesource.com' (ANSI_X3.4-1968) -> 'https://deb.nodesource.com' (UTF-8)
--2016-11-16 12:11:34-- https://deb.nodesource.com/
Resolving deb.nodesource.com (deb.nodesource.com)... 52.222.157.79, 52.222.157.43, 52.222.157.145, ...
Connecting to deb.nodesource.com (deb.nodesource.com)|52.222.157.79|:443... connected.
gnutls[5]: REC[0x20578e0]: Allocating epoch #0
gnutls[3]: ASSERT: gnutls_constate.c:586
gnutls[5]: REC[0x20578e0]: Allocating epoch #1
gnutls[4]: HSK[0x20578e0]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B)
[..]
gnutls[4]: HSK[0x20578e0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_128_SHA1 (00.66)
gnutls[4]: EXT[0x20578e0]: Sending extension STATUS REQUEST (5 bytes)
gnutls[4]: EXT[0x20578e0]: Sending extension SERVER NAME (23 bytes)
gnutls[4]: EXT[0x20578e0]: Sending extension SAFE RENEGOTIATION (1 bytes)
gnutls[4]: EXT[0x20578e0]: Sending extension SESSION TICKET (0 bytes)
gnutls[4]: EXT[0x20578e0]: Sending extension SUPPORTED ECC (12 bytes)
gnutls[4]: EXT[0x20578e0]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
gnutls[4]: EXT[0x20578e0]: sent signature algo (4.1) RSA-SHA256
[...]
gnutls[4]: EXT[0x20578e0]: sent signature algo (2.3) ECDSA-SHA1
gnutls[4]: EXT[0x20578e0]: Sending extension SIGNATURE ALGORITHMS (28 bytes)
gnutls[4]: EXT[0x20578e0]: Sending extension DUMBFW (238 bytes)
gnutls[4]: HSK[0x20578e0]: CLIENT HELLO was queued [518 bytes]
gnutls[5]: REC[0x20578e0]: Preparing Packet Handshake(22) with length: 518 and min pad: 0
gnutls[5]: REC[0x20578e0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 523
gnutls[3]: ASSERT: gnutls_buffers.c:1104
gnutls[5]: REC[0x20578e0]: SSL 3.3 Alert packet received. Epoch 0, length: 2
gnutls[5]: REC[0x20578e0]: Expected Packet Handshake(22)
gnutls[5]: REC[0x20578e0]: Received Packet Alert(21) with length: 2
gnutls[5]: REC[0x20578e0]: Decrypted Packet[0] Alert(21) with length: 2
gnutls[5]: REC[0x20578e0]: Alert[2|40] - Handshake failed - was received
gnutls[3]: ASSERT: gnutls_record.c:801
gnutls[3]: ASSERT: gnutls_record.c:808
gnutls[3]: ASSERT: gnutls_record.c:1328
gnutls[3]: ASSERT: gnutls_buffers.c:1355
gnutls[3]: ASSERT: gnutls_handshake.c:1428
gnutls[3]: ASSERT: gnutls_handshake.c:2699
GnuTLS: A TLS fatal alert has been received.
GnuTLS: received alert [40]: Handshake failed
gnutls[5]: REC[0x20578e0]: Start of epoch cleanup
gnutls[5]: REC[0x20578e0]: End of epoch cleanup
gnutls[5]: REC[0x20578e0]: Epoch #0 freed
gnutls[5]: REC[0x20578e0]: Epoch #1 freed
Unable to establish SSL connection.
hanikesn
on 16 Nov 2016
For anyone who can temporarily live with http instead of https, this works for us: https://github.com/cargomedia/puppet-packages/pull/1570 - package's integrity/signature is still being verified, transport is unencrypted. Not optimal, but the reality for most of the deb pacakges out there
ppp0
on 16 Nov 2016
Thanks all for posting - we're investigating from our side and are in touch with AWS to gather more information. I will update this issue with more information as it becomes available.
mweagle
on 16 Nov 2016
Our (Docker) team is also in contact with AWS. So far it appears to be an issue on their side (but not confirmed yet), and fails on distros running an older version of gnutils (Ubuntu 14.04, Ubuntu 12.04)
thaJeztah
on 16 Nov 2016
Thanks @thaJeztah - that matches what I've found as well. Continuing to investigate.
mweagle
on 16 Nov 2016
Update: we (Docker) got informed that AWS identified a possible cause and is rolling out updates. It may take some time for those to be available everywhere. Hopefully the issue will be resolved by that. Keep us posted if the problem maintains, because the issue depends on which CDN mirror is picked by your machine.
Don't forget to revert workarounds (e.g. overrides in /etc/hosts or removing https) :smile:
thaJeztah
on 16 Nov 2016
Thanks for the feedback! I confirm it's getting fixed indeed. Successfully tested using Ubuntu 14.04.5 LTS from EC2 instance in eu-central-1.
chdeliens
on 16 Nov 2016
Confirmed fixed on Jessie 8.6, from Austria.
zoltrain
on 16 Nov 2016
Working for me too from eu-west-1 and also locally 馃憤
karlatkinson
on 16 Nov 2016
Thanks for the info @thaJeztah - AWS also confirmed the issue and a potential fix is being rolled out. If it's not resolved in your region, please wait a bit and retry until all CDN mirrors are updated.
mweagle
on 16 Nov 2016
Confirmed fix is being made available:
docker run --rm -it debian:stable sh -c "apt-get update; apt-get install -y wget; GNUTLS_DEBUG_LEVEL=7 wget https://deb.nodesource.com"
...
gnutls[5]: REC[0x2a5fbd0]: Decrypted Packet[64] Application Data(23) with length: 113
index.html [ <=> ] 81.91K 451KB/s in 0.2s
2016-11-16 16:22:53 (451 KB/s) - 'index.html' saved [83874]
Thanks, it works for me too!
ghusse
on 16 Nov 2016
This issue is not yet resolved for me:
Failed to fetch https://deb.nodesource.com/node_6.x/dists/jessie/main/source/Sources gnutls_handshake() failed: Handshake failed
see: https://travis-ci.org/TheTorProject/ooni-measurements/builds/176429312#L1680
hellais
on 16 Nov 2016
@hellais - It looks like build 56 successfully completed. Is this issue resolved for you now? TIA.
mweagle
on 16 Nov 2016
@mweagle yes it's now fixed. Probably related to the fix not having propagated to all cloudfront locations.
hellais
on 16 Nov 2016
I'm still having issues where it fails to download the gpg.key (US-central).
gpg keys are sometimes downloading successfully, but not always. Probably still some issues wiht the propagation.
deddu
on 16 Nov 2016
Confirming as fixed (APAC). Thanks guys.
Hashfyre
on 17 Nov 2016
Another option, on Debian 9, is to remove the package libgnutls-deb0-28, as seen at: https://stackoverflow.com/a/41318564/781153
dugwood
on 1 Aug 2017
I am having the same problem since today (AWS CodeBuild image with Ubuntu 14.04):
Failed to fetch https://deb.nodesource.com/node_10.x/dists/trusty/main/source/Sources gnutls_handshake() failed: Handshake failed
with the following command:
curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
sudo apt-get install -y nodejs
Is anyone experiencing this?
Thank you in advance.
jonsnowseven
on 20 May 2020
I have the same problem Ubuntu 14.04
root@desenvolvimento:/home/bernardo# cat /etc/apt/sources.list.d/nodesource.list
deb https://deb.nodesource.com/node_10.x trusty main
deb-src https://deb.nodesource.com/node_10.x trusty main
I've run
curl --silent https://deb.nodesource.com/gpgkey/nodesource.gpg.key | sudo apt-key add -
and the error continues
W: Falhou ao buscar https://deb.nodesource.com/node_10.x/dists/trusty/main/source/Sources gnutls_handshake() failed: Handshake failed
W: Falhou ao buscar https://deb.nodesource.com/node_10.x/dists/trusty/main/binary-amd64/Packages gnutls_handshake() failed: Handshake failed
W: Falhou ao buscar https://deb.nodesource.com/node_10.x/dists/trusty/main/binary-i386/Packages gnutls_handshake() failed: Handshake failed
with node 12.x same error
root@desenvolvimento:/home/bernardo# gnutls-cli -V -p 443 deb.nodesource.com
Resolving 'deb.nodesource.com'...
Connecting to '2001:12f0:210::c88f:f709:443'...
* Fatal error: A TLS fatal alert has been received.
Received alert [40]: Handshake failed
** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.
dioubernardo
on 20 May 2020
Not sure if that's the cause but;
Ubuntu 14.04 LTS reaches end of life on April 30, 2019, five years after it was first released. End of Life (EOL) status marks the end of all support. There will be no further security updates, package updates, or maintenance updates to Ubuntu 14.04 LTS for desktop or server
thaJeztah
on 20 May 2020
Hello.
curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
sudo apt-get install -y nodejs
This command is working now. Not sure what changed in the meanwhile.
@dioubernardo and @thaJeztah, is it working for you?
jonsnowseven
on 21 May 2020
The incompatibility between the certificate ciphers and those available in Ubuntu Trusty Tahr 14.04 caused this issue.
Please all confirm that it works correctly and sorry for the inconvenience.
igsu
on 21 May 2020
I tested it now and returned to normal
I didn't change anything
dioubernardo
on 21 May 2020
Related issues
thameemk612
路
3Comments
maane018
路
5Comments
christalk
路
5Comments
normangilmore
路
4Comments
jtyr
路
4Comments
Most helpful comment
Thanks all for posting - we're investigating from our side and are in touch with AWS to gather more information. I will update this issue with more information as it becomes available.