On Tue, May 02, 2023 at 02:35:05AM -0400, gs-debian....@gluelogic.com wrote: > On Fri, Apr 21, 2023 at 01:47:22PM -0400, gs-debian....@gluelogic.com wrote: > > On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote: > > > On Apr 21, gs-debian....@gluelogic.com wrote: > > > > > > > I probably should have started with the most basic thing: > > > > > > > > What is the date on your device? > > > NTP-accurate. > > > > Perhaps there is something amiss in the Debian 32-bit build of lighttpd > > or openssl for aarch64. (Is there any particular reason that you are > > running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?) > > Apologies for the delay. I installed Debian Bookworm onto a QEMU > aarch64 VM and the (64-bit!) lighttpd package for Debian aarch64 works > as expected when I tested with an expired LE cert (warning issued), and > when I tested with a current LE cert (no warning issued). > > From where did you obtain a 32-bit build of lighttpd for aarch64? > If you know, how was that 32-bit lighttpd built? I would like to try to > reproduce (as closely as possible) the 32-bit build.
Is your system based on raspbian? My understanding is that a while back, raspbian was using a 32-bit kernel and 32-bit userland, even on aarch64-capable ARM chips. Then, they upgraded the kernel to be 64-bit on aarch64-capable ARM chips, but userland may still be 32-bit. In any case, I have tested that things work as expected for me on a physical 32-bit ARM processor running 32-bit lighttpd, and on a 64-bit ARM VM running 64-bit lighttpd. I'll need more info to get any further. You might try testing using lighttpd mod_gnutls instead of mod_openssl to see if that makes a difference. If it does, then the issue might be in the 32-bit armhf build of openssl that you are running under your aarch64 kernel. Cheers, Glenn
