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