On Fri, Jun 24, 2022 at 4:35 AM Petr Pisar <petr.pi...@atlas.cz> wrote: > > V Wed, Jun 22, 2022 at 06:42:44PM -0500, KeithG napsal(a): > > On Wed, Jun 22, 2022 at 12:16 PM Petr Pisar <petr.pi...@atlas.cz> wrote: > > > That patch does not seem right. gnutls_x509_crt_get_expiration_time() > > > returns > > > time_t and now is also time_t. > > > > > > Either there is a bug in gnutls, or glibc, or simply the expiration time > > > of > > > the certificate is not representable with 32-bit time_t type. I would not > > > be > > > surprised if it were the last case. > > > > > > Can you post here a complete certificate chain the server presents to > > > wget? > > > You can use "openssl s_client -connect THE_HOST:https -showcerts to > > > obtain it. > > > If it so, than the only fix is to recompile your system with > > > "-D_TIME_BITS=64 > > > -D_FILE_OFFSET_BITS=64" CFLAGS. (Provided your platform supports it.) > > > > > > -- Petr > > > > I am not sure what I need to reply when the command completes. I typed > > '0'. This is on an armv7 running arch linux: > > > > # openssl s_client -connect google.com:https -showcerts > > CONNECTED(00000003) > > depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1 > > verify return:1 > > depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 > > verify return:1 > > depth=0 CN = *.google.com > > verify return:1 > > --- > > Certificate chain > > 0 s:CN = *.google.com > > i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 > > The certificates look good. Their timestamps fit into 32-bit time_t > resolution. > > Are you sure a machine where wget fails has correctly set clock? The server > certificate expires on Aug 29 08:29:45 2022 GMT. > > I tried wget-1.21.3 built with GnuTLS on i686 machine, which is also 32-bit > platform, with Fedora operating system and I don't observe any failure. > > Can you try using GnuTLS client directly on the affected system? Make sure > an argument of --x509cafile option points to a file with all CA certificates: > > gnutls-cli --x509cafile /etc/ssl/certs/ca-bundle.crt --port https google.com > > If this is a bug in GnuTLS (or some of its libraries), it should fail, > too. > > -- Petr
Petr, Well, once again, I am not sure how to use this command. When it waited for input, I typed 0. This is what it reported: # gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt --port https google.com Processed 141 CA certificate(s). Resolving 'google.com:https'... Connecting to '142.251.32.14:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `CN=*.google.com', issuer `CN=GTS CA 1C3,O=Google Trust Services LLC,C=US', serial 0x58ace5940b417864129d531a39cb0067, EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2022-06-06 08:29:46 UTC', expires `2022-08-29 08:29:45 UTC', pin-sha256="TVChrtTOiGvjGdQIZ3RIvpmzut12LaJKHQdZOLnNUEk=" Public Key ID: sha1:b4d72943613a2630de62c3e21029deba02492767 sha256:4d50a1aed4ce886be319d408677448be99b3badd762da24a1d075938b9cd5049 Public Key PIN: pin-sha256:TVChrtTOiGvjGdQIZ3RIvpmzut12LaJKHQdZOLnNUEk= - Certificate[1] info: - subject `CN=GTS CA 1C3,O=Google Trust Services LLC,C=US', issuer `CN=GTS Root R1,O=Google Trust Services LLC,C=US', serial 0x0203bc53596b34c718f5015066, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-08-13 00:00:42 UTC', expires `2027-09-30 00:00:42 UTC', pin-sha256="zCTnfLwLKbS9S2sbp+uFz4KZOocFvXxkV06Ce9O5M2w=" - Certificate[2] info: - subject `CN=GTS Root R1,O=Google Trust Services LLC,C=US', issuer `CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE', serial 0x77bd0d6cdb36f91aea210fc4f058d30d, RSA key 4096 bits, signed using RSA-SHA256, activated `2020-06-19 00:00:42 UTC', expires `2028-01-28 00:00:42 UTC', pin-sha256="hxqRlPTu1bMS/0DITB1SSu0vd4u/8l8TjPgfaAp63Gc=" - Status: The certificate is trusted. - Description: (TLS1.3-X.509)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) - Session ID: 7F:0D:EB:E2:55:CF:B7:38:EF:C4:73:7C:3B:8F:C0:E4:C8:47:60:BA:E6:C1:1F:D2:20:99:42:A4:3F:C3:68:69 - Options: - Handshake was completed - Simple Client Mode: 0 HTTP/1.0 400 Bad Request Content-Type: text/html; charset=UTF-8 Referrer-Policy: no-referrer Content-Length: 1555 Date: Tue, 28 Jun 2022 00:59:23 GMT <!DOCTYPE html> <html lang=en> <meta charset=utf-8> <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width"> <title>Error 400 (Bad Request)!!1</title> <style> *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px} </style> <a href=//www.google.com/><span id=logo aria-label=Google></span></a> <p><b>400.</b> <ins>That’s an error.</ins> <p>Your client has issued a malformed or illegal request. <ins>That’s all we know.</ins> *** Fatal error: The TLS connection was non-properly terminated. *** Server has terminated the connection abnormally. My clock seems to be correct: # timedatectl Local time: Mon 2022-06-27 20:03:44 CDT Universal time: Tue 2022-06-28 01:03:44 UTC RTC time: n/a Time zone: America/Chicago (CDT, -0500) System clock synchronized: yes NTP service: active RTC in local TZ: no