Public key verification fails on many legitimate URLs, one example:
{{{
$ curl -I https://duckduckgo.com
curl: (35) gnutls_handshake() failed: Public key signature verification has failed.
$ curl --version
curl 7.50.1 (x86_64-pc-linux-gnu) libcurl/7.50.1 GnuTLS/3.5.3 zlib/1.2.8 libidn/1.33 libssh2/1.7.0 nghttp2/1.13.0 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM
NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets
}}}
it works perfect if downgraded to 7.38.0-4+deb8u3:
{{{
$ curl -I https://duckduckgo.com
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 18 Aug 2016 10:03:59 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 5009
Connection: keep-alive
ETag: "57b56e74-1391"
Expires: Thu, 18 Aug 2016 10:03:58 GMT
Cache-Control: no-cache
Strict-Transport-Security: max-age=31536000
Accept-Ranges: bytes
$ curl --version
curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1t zlib/1.2.8 libidn/1.33 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL
libz TLS-SRP
}}}
I'm seeing all https accesses failing with curl. Connecting to the same
sites with gnutls-cli works OK.
tim@ermintrude:~$ curl-config --ca
/etc/ssl/certs/ca-certificates.crt
tim@ermintrude:~$ curl -V
curl 7.50.1 (x86_64-pc-linux-gnu) libcurl/7.50.1 GnuTLS/3.5.4 zlib/1.2.8 libidn/1.33 libssh2/1.7.0 nghttp2/1.14.1 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets
tim@ermintrude:~$ curl -vv https://packages.debian.org/
* Trying 128.31.0.51...
* Connected to packages.debian.org (128.31.0.51) port 443 (#0)
* found 175 certificates in /etc/ssl/certs/ca-certificates.crt
* found 702 certificates in /etc/ssl/certs
* ALPN, offering h2
* ALPN, offering http/1.1
* gnutls_handshake() failed: Public key signature verification has failed.
* Closing connection 0
curl: (35) gnutls_handshake() failed: Public key signature verification has failed.
tim@ermintrude:~$ gnutls-cli --x509cafile=/etc/ssl/certs/ca-certificates.crt -V packages.debian.org 443
Processed 175 CA certificate(s).
Resolving 'packages.debian.org:443'...
Connecting to '5.153.231.3:443'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
- X.509 Certificate Information:
Version: 3
Serial Number (hex): 03347b1421ebf70305b161317e6d2a634bab
Issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
Validity:
Not Before: Fri Sep 16 00:36:00 UTC 2016
Not After: Thu Dec 15 00:36:00 UTC 2016
Subject: CN=packages.debian.org
Subject Public Key Algorithm: RSA
Algorithm Security Level: High (4096 bits)
[....]
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----
- Status: The certificate is trusted.
- Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM)
- Session ID: 8E:71:45:94:73:64:AB:50:3B:E7:A7:E8:19:FB:33:2D:4B:E7:21:87:2A:7A:F3:BC:D3:84:FB:A5:FD:3D:31:73
- Ephemeral EC Diffie-Hellman parameters
- Using curve: SECP256R1
- Curve size: 256 bits
- Version: TLS1.2
- Key Exchange: ECDHE-RSA
- Server Signature: RSA-SHA256
- Cipher: AES-256-GCM
- MAC: AEAD
- Compression: NULL
- Options: safe renegotiation,
- Channel binding 'tls-unique': 80ae75b45d750a3230320aca
- Handshake was completed
- Simple Client Mode:
I fixed this on a sid install by removing libgnutls-deb0-28 which was being kept around by an old librtmp1 package version, left over from Jessie debian-multimedia. Possibly libcurl should conflict with this package?
Confirm that Tim Small solution worked for me as well. I am running Debian Stretch and removing libgnutls-deb0-28 fixed the error.
Dear Maintainer, As Tim Small said in a previous message, removing libgnutls-deb0-28 solve the problem. Note: I have installed curl 7.51.0-1 in jessie from stretch package swiching the repos from stable to testing without problem.
Dear Maintainer, We notice that after upgrading the package libcurl3-gnutls from version 7.38.0-4+deb8u6 to 7.52.1-5+deb9u1 that we get errors when running apt-get update. The errors only occur on repositories that use https. You can find an example below. For now we downgraded the packages to version 7.38.0-4+deb8u6 as a workaround, this allows us to keep getting updates from the repositories affected. But for servers running stretch, we couldn't downgrade without changing the repositories from stretch to jessie, which is something that we prefer not to do. Is there a fix available already or do we need to wait? Example error: ################################################################################ W:Failed to fetch https://apt.datadoghq.com/dists/stable/main/binary-amd64/Packages gnutls_handshake() failed: Public key signature verification has failed. ################################################################################ Thank you in advance for your reply. Best regards, Jens Van Nieuwenhuyze Sentia operations team operations@be.sentia.com
On Wed, 28 Sep 2016 12:57:49 +0100 Tim Small wrote: > Package: curl > Followup-For: Bug #834724 > > I fixed this on a sid install by removing libgnutls-deb0-28 which was > being kept around by an old librtmp1 package version, left over from > Jessie debian-multimedia. Possibly libcurl should conflict with this > package? > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core) > Locale: LANG
Roxanna Gabriela Quintanilla Cantu te envió un correo electrónico con el modo confidencial de Gmail: [image: Logotipo de Gmail]Re: curl: (35) gnutls_handshake() failed: Public key signature verification has failed. <https://confidential-mail.google.com/msg/AA12eCh0Ye_7UjIjbubwpqFtK2MsHZZBjkkYcfx-9QEbNGpB0hLWFVbnWqrrB7PLRpkzWzdXaF07DpT5caxNopXiUaGYjdhnCjcijDY2KU86Rwu4OCC11fu9yMtCMuuq1y2YT31dfIbAzHsJptkgLvA1Br1vYJ9dybr2K2aCdjlwogeI> Este mensaje se envió el 31 mar. 2020 a las 00:47:32 GMT-7 Puedes abrir el mensaje con el siguiente vínculo, que solo funcionará para 834724@bugs.debian.org. Ver correo electrónico <https://confidential-mail.google.com/msg/AA12eCh0Ye_7UjIjbubwpqFtK2MsHZZBjkkYcfx-9QEbNGpB0hLWFVbnWqrrB7PLRpkzWzdXaF07DpT5caxNopXiUaGYjdhnCjcijDY2KU86Rwu4OCC11fu9yMtCMuuq1y2YT31dfIbAzHsJptkgLvA1Br1vYJ9dybr2K2aCdjlwogeI> El Modo confidencial de Gmail te da más control sobre los mensajes que envías. Es posible que el remitente haya elegido establecer una fecha de vencimiento, inhabilitar la impresión o el reenvío, o dar seguimiento al acceso a este mensaje. Más información <https://support.google.com/mail/answer/7674059> Gmail, el correo electrónico de Google El uso está sujeto a la Política de Privacidad de Google <https://myaccount.google.com/privacypolicy?hl=es-419> Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, EE.UU. Recibiste este mensaje porque alguien te envió un correo electrónico con el modo confidencial de Gmail. [image: Logotipo de Google]
R my phone still hacked
در تاریخ یکشنبه ۲۵ اکتبر ۲۰۲۰، ۱۶:۰۳ Debian Bug Tracking System < owner@bugs.debian.org> نوشت:
maris
Sarim.love.mak.7
variable-length subnet mask (VLSM) for android. http://Gaak.co/ab3ufx Stáhnout Outlook pro Android<https://aka.ms/AAb9ysg>
Mehdi khanpor
Enviado do meu smartphone Samsung Galaxy.
Redmi/cannong_eea/cannong:11/RP1A.200720.011/V12.5.10.0.RJEEUVF:user/release-keys
1000261835642 Get Outlook for Android<https://aka.ms/AAb9ysg>
7.38.0-4+deb8u6 to 7.52.1-5+deb9u1 that we get errors when running apt-get update. The errors only occur on repositories that use https. workaround, this allows us to keep getting updates from the repositories affected. But for servers running stretch, we couldn't downgrade without changing the repositories from stretch to jessie, which is something that we prefer not to do. Is there a fix available already or do we need to wait? ################################################################################ ################################################################################ (charmap=ANSI_X3.4-1968)
My: Name is Asad Shadali My gmail is dsayidomar@gmail.com My.NO.:+251915003598
Sent from Yahoo Mail on Android
Get Outlook for Android<https://aka.ms/AAb9ysg>
Sent from Yahoo Mail on Android
Google Rafal Franczak Rafal Franczak Udostępniam Ci swój profil Zobacz w Mapach Google Google © 2018 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043 Wysłane przez: Rafal Franczak w Mapach Google
On Mon, 1 Aug 2022 02:29:54 -0500 Flor Canales <canalesflor853@gmail.com> wrote: wait? ################################################################################ ################################################################################