V Tue, Jun 21, 2022 at 10:54:47PM -0500, KeithG napsal(a):
> With the latest wget 1.21.3 on arch linux on armv7, I was experiencing
> a 'certificate expired' error. This has been going on for a while but
> only on my 32 bit machine. The 64 bit version never had a problem on
> x86_64 or aarch64. 1.21.1 did not have this problem on 32 bit
> machines, either. I was able to resolve the issue by a patch found in
> this thread:
> https://archlinuxarm.org/forum/viewtopic.php?f=57&t=16070&p=69630#p69630
> I still have test problems for the iri tests, but this patch does fix
> the https certificate bug on arch arm armv7 and maybe other 32 bit OS.
> 

       time_t now = time (NULL);
       [...]
--- wget-1.21.3.org/src/gnutls.c    2022-02-26 15:47:42.000000000 +0100
+++ wget-1.21.3/src/gnutls.c    2022-06-21 20:51:40.244552644 +0200
@@ -1085,7 +1085,7 @@
           logprintf (LOG_NOTQUIET, _("The certificate has not yet been 
activated\n"));
           success = false;
         }
-      if (now >= gnutls_x509_crt_get_expiration_time (cert))
+      if (now >= (unsigned long) gnutls_x509_crt_get_expiration_time (cert))
         {
           logprintf (LOG_NOTQUIET, _("The certificate has expired\n"));
           success = false;

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

Attachment: signature.asc
Description: PGP signature

Reply via email to