wget says The certificate has expired

[solskogen]

But my date is correct (which usually is the problem) - I've tried multiple sites and I'm quite sure that the certificate has NOT expired This is on a Pi400 running armv7l

[ufo6000]

Hello,
please post the output of $this->bbcode_second_pass_code('', 'timedatectl') and also an example for wget, command line and output.

[solskogen]

$this->bbcode_second_pass_code('', '[solskogen@alarmpi ~]$ timedatectl
Local time: Mon 2022-06-13 08:46:03 CEST
Universal time: Mon 2022-06-13 06:46:03 UTC
RTC time: n/a
Time zone: Europe/Oslo (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
')

$this->bbcode_second_pass_code('', '[solskogen@alarmpi ~]$ wget https://cdn.cloudflare.steamstatic.com/client/installer/steam.deb
--2022-06-13 08:46:01-- https://cdn.cloudflare.steamstatic.com/client/installer/steam.deb
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving cdn.cloudflare.steamstatic.com (cdn.cloudflare.steamstatic.com)... 104.18.37.23, 172.64.150.233
Connecting to cdn.cloudflare.steamstatic.com (cdn.cloudflare.steamstatic.com)|104.18.37.23|:443... connected.
The certificate has expired
')

[ufo6000]

Thanks, I can confirm the bug on my rpi,
all HTTPS sites are broken with wget.

$this->bbcode_second_pass_code('', '
$ wget https://google.com
--2022-06-13 12:29:39-- https://google.com/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving google.com (google.com)... 2a00:1450:4001:810::200e, 216.58.212.142
Connecting to google.com (google.com)|2a00:1450:4001:810::200e|:443... connected.
The certificate has expired
')

Strange, wget or ca-certificates was not updated in the last weeks, but gnutls was. downgrading package gnutls (3.7.6-1 => 3.7.5-1) does not solve the issue, but gives another error type:

$this->bbcode_second_pass_code('', '
$ wget https://google.com
--2022-06-13 12:30:10-- https://google.com/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving google.com (google.com)... 2a00:1450:4001:810::200e, 142.250.185.78
Connecting to google.com (google.com)|2a00:1450:4001:810::200e|:443... connected.
The certificate has not yet been activated
')

As workaround use curl, which uses openssl.

[matofesi]

I think I've found direct cause of the problem... When wget checks certificate validity it compares current time as time_t (which should be "long long int") with the result of gnutls_x509_crt_get_expiration_time function that should also return time_t. Problem is when getting current time it gets 32 bits of data (of course it's really 64, but top half is filled with zeroes) while the certificate validity returns 64 bits with the "correct" 32 being the lowest half. If you compare both times directly it gives you an error but if you cast the certificate time to unsigned long first it returns correct comparison and everything seems to be working fine.

Unfortunately I'm not really sure which part of the update is the actual culprit - I just added the cast (gnutls.c, line 1088 for wget-1.21.3), recompiled and it works just fine.

[keithspg]

I was just pointed here as I was having the same problem. It is curious that the old armv6 image works (wget version 1.21.2-1) as does the current aarch64 (wget 1.21.3-1) , but the armv7 which uses the same wget version is the one that fails.

Can you post the patch?

Keith

[matofesi]

It's just one changed line so I didn't bother to make a patch, but here you are

[keithspg]

Got it. Thanks. Did you post this to the gnu wget group as a bug fix? My guess is that this is a problem with the 32 bit OSes but not 64 bit as I am not having a problem with the aarch64 installation with wget.

Keith

[keithspg]

I can confirm that on armv7 that this patch fixes this problem with wget.

How did you get it to compile? I used the arch PKGBUILD and added the appropriate architectures and when I tried to build it on aarch64, I get a failure.
$this->bbcode_second_pass_code('', '============================================================================
Testsuite summary for wget 1.21.3
============================================================================
# TOTAL: 94
# PASS: 87
# SKIP: 1
# XFAIL: 0
# FAIL: 6
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
Please report to bug-wget@gnu.org
============================================================================
make[4]: *** [Makefile:2103: test-suite.log] Error 1
')
and it fails to build an executable. I comment out the tests and it builds.
The failed tests are ftp-iri, ftp-iri-fallback, ftp-iri-recursive, ftp-iri-disabled, iri-disabled, iri-list

When I try on armv7, I get 11 test failures. The same 6 as above plus: https-pfs, https-tlsv1, https-tlsv1x, https-clientcert, https-crl. When I add your patch, I am back to the same 6 test failures as with aarch64. This cast patch fixes this problem with the https certificate check for armv7.
The questions I have are 1) how did this binary get built from the PKGBUILD in the first place for armv7 and aarch64 and 2) what else needs to get fixed for the iri faiulres (whatever they are). AFAIK, the PKGBUILDS for the Arch Arm packages are what is used to build the binaries. Many are copies of the x86_64 PKGBUILDS and need only to add the proper architecture to build. I do not understand how nobody saw that it was not building properly.
I am using this in a script to check if I am online:
$this->bbcode_second_pass_code('', 'wget --force-html --spider --connect-timeout=1 --timeout=10 --tries=2 https://www.google.com/')
and now after this patch, it works properly, I get this as a response which matches what I get on aarch64 and x86_64:
$this->bbcode_second_pass_code('', '# wget --force-html --spider --connect-timeout=1 --timeout=10 --tries=2 https://www.google.com/
Spider mode enabled. Check if remote file exists.
--2022-06-21 13:18:07-- https://www.google.com/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving www.google.com (www.google.com)... 142.250.190.132, 2607:f8b0:4009:81b::2004
Connecting to www.google.com (www.google.com)|142.250.190.132|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.')

[matofesi]

I didn't post it anywhere else as I don't think this change really fixes the issue. I've checked wget sources and nothing significant changed in the gnutls part. I also checked gnutls briefly in the part where validity dates are checked and there does not seem to be any significant change there either. So I think the problem lies somewhere deeper - my last system update was a big one including glibc and kernel and I suspect that something changed in time_t implementation on 32 bit ARM that initializes variables differently.

But as I really don't like/don't know that well C/C++ I won't be investigating any further. I'll just wait until next update of wget/gnutls/etc. and see what is going to happen