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
signature.asc
Description: PGP signature