Bug#1034586: always reports inactive/expired certificate on armhf
tobias.jakobi.compleo added more details in https://redmine.lighttpd.net/issues/3244 The issue appears to be lighttpd being built with 64-bit time_t, but the underlying openssl library being built with 32-bit time_t *and* exposing an API interface using time_t. The result is that lighttpd might issue error trace that a certificate is expired when the certificate is not expired. There should be no other ill-effect besides the error trace at startup. However, some distros have startup scripts which check config syntax, and will treat `lighttpd -f /etc/lighttpd/lighttpd.conf -tt` as an error if there is error trace, even if the lighttpd command exits 0 (success) that the syntax is valid. --- Most OS distros have migrated or are in the process of migrating to 64-bit time_t. However, lighttpd 1.4.75 will contain a workaround for older systems to address this issue with older libraries on armhf.
Bug#1034586: always reports inactive/expired certificate on armhf
Marco, please review my previous messages and try to help provide additional information. Thank you. Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
Macro, please review my previous messages and try to help provide additional information. Thank you. Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
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
Bug#1034586: always reports inactive/expired certificate on armhf
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. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
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?)
If you are able to build lighttpd on your aarch64, you can use my
local (internal) code to parse ASN1_TIME, rather than the openssl
ASN1_TIME_cmp_time_t() routine to parse and compare. (Be sure to build
32-bit for testing to better match your current system configuration.)
For *testing only*, the following patch "disables" the check for openssl
1.1.1, which added ASN1_TIME_cmp_time_t(), so that the local (internal)
ASN1_TIME parsing is used.
--- a/src/mod_openssl.c
+++ b/src/mod_openssl.c
@@ -1272,7 +1272,7 @@ network_ssl_servername_callback (SSL *ssl, int *al, void
*srv)
#endif
-#if OPENSSL_VERSION_NUMBER < 0x10101000L \
+#if OPENSSL_VERSION_NUMBER < 0xL \
|| defined(BORINGSSL_API_VERSION) \
||(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x306fL)
static unix_time64_t
@@ -1291,7 +1291,7 @@ mod_openssl_cert_is_active (const X509 *crt)
{
const ASN1_TIME *notBefore = X509_get0_notBefore(crt);
const ASN1_TIME *notAfter = X509_get0_notAfter(crt);
- #if OPENSSL_VERSION_NUMBER < 0x10101000L \
+ #if OPENSSL_VERSION_NUMBER < 0xL \
|| defined(BORINGSSL_API_VERSION) \
||(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <
0x306fL)
const unix_time64_t before = mod_openssl_asn1_time_to_posix(notBefore);
Bug#1034586: always reports inactive/expired certificate on armhf
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. -- ciao, Marco signature.asc Description: PGP signature
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 09:38:31AM +0200, Marco d'Itri wrote: > On Apr 21, gs-debian@gluelogic.com wrote: > > > What your `uname -a` ? > Linux omitted.mi.bofh.it 6.1.0-7-arm64 #1 SMP Debian 6.1.20-2 (2023-04-08) > aarch64 GNU/Linux > > > What is the output of the following for you? > > $ lighttpd -V | grep "Y2038 support" > > + Y2038 support > Same. I probably should have started with the most basic thing: What is the date on your device? If the `date` is incorrect, e.g. starts at 1970 after reboot, then that might explain lighttpd's trace when starting lighttpd.
Bug#1034586: always reports inactive/expired certificate on armhf
On Apr 21, gs-debian@gluelogic.com wrote: > What your `uname -a` ? Linux omitted.mi.bofh.it 6.1.0-7-arm64 #1 SMP Debian 6.1.20-2 (2023-04-08) aarch64 GNU/Linux > What is the output of the following for you? > $ lighttpd -V | grep "Y2038 support" > + Y2038 support Same. Thank you for your help. -- ciao, Marco signature.asc Description: PGP signature
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 07:41:13AM +0200, Marco d'Itri wrote: > On Apr 21, gs-debian@gluelogic.com wrote: > > > Please confirm you are running an arm64 kernel, as you posted above. > Confirmed. What your `uname -a` ? What is the output of the following for you? $ lighttpd -V | grep "Y2038 support" + Y2038 support I'll build a Debian VM image this weekend to try to repro with the Debian packages. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Apr 21, gs-debian@gluelogic.com wrote: > Please confirm you are running an arm64 kernel, as you posted above. Confirmed. > What lighttpd package (from which architecture) do you have installed? > $ file /usr/sbin/lighttpd root@omitted:~# /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf -tt 2023-04-21 07:37:51: (mod_openssl.c.1335) SSL: inactive/expired X509 certificate '/var/lib/dehydrated/certs/omitted.mi.bofh.it/fullchain.pem' root@omitted:~# file /usr/sbin/lighttpd /usr/sbin/lighttpd: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=414352134318885ffaf3dbf10c3b87590cdcddaf, for GNU/Linux 3.2.0, stripped root@omitted:~# ldd /usr/sbin/lighttpd linux-vdso.so.1 (0xf7ee6000) libpcre2-8.so.0 => /lib/arm-linux-gnueabihf/libpcre2-8.so.0 (0xf7e1) libnettle.so.8 => /lib/arm-linux-gnueabihf/libnettle.so.8 (0xf7db) libxxhash.so.0 => /lib/arm-linux-gnueabihf/libxxhash.so.0 (0xf7d9) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf7c79000) /lib/ld-linux-armhf.so.3 (0xf7ee7000) root@omitted:~# ldd /usr/lib/lighttpd/mod_openssl.so linux-vdso.so.1 (0xf7b38000) libssl.so.3 => /lib/arm-linux-gnueabihf/libssl.so.3 (0xf7abc000) libcrypto.so.3 => /lib/arm-linux-gnueabihf/libcrypto.so.3 (0xf780) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf76e9000) /lib/ld-linux-armhf.so.3 (0xf7b39000) root@omitted:~# -- ciao, Marco
Bug#1034586: always reports inactive/expired certificate on armhf
On Wed, Apr 19, 2023 at 01:39:02AM +0200, Marco d'Itri wrote: > Package: lighttpd > Version: 1.4.69-1 > Severity: normal > > I am using the latest openssl and lighttpd packages on an armhf (with an > arm64 kernel) and an amd64 system, and only on the armhf system I always > get this warning at startup even just after having created a Let's > Encrypt certificate. > > Apr 19 01:23:31 omitted.mi.bofh.it lighttpd[8876]: 2023-04-19 01:23:30: > (mod_openssl.c.1335) SSL: inactive/expired X509 certificate > '/var/lib/dehydrated/certs/omitted.mi.bofh.it/fullchain.pem' > > # openssl x509 -noout -text -in > /var/lib/dehydrated/certs/bokassa.mi.bofh.it/fullchain.pem | grep -A2 Validity > Validity > Not Before: Apr 18 22:13:45 2023 GMT > Not After : Jul 17 22:13:44 2023 GMT > > After looking at > https://github.com/lighttpd/lighttpd1.4/blob/fdb7ffed88b9dfe09a51e7fb58e5ddfe938c1ec9/src/mod_openssl.c#L1284 > > I wonder if this is common on all 32 bit systems instead. No, this is not common on all 32-bit systems, though I am curious as to why you are seeing that warning with a valid certificate. To try to reproduce this, I took some LE certs and put them on a 32-bit ARM system I have (which is running openwrt, not Debian) $ uname -m armv7l $ cat /proc/cpuinfo | egrep "model|Features" model name : ARMv7 Processor rev 1 (v7l) Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 $ file /usr/sbin/lighttpd /usr/sbin/lighttpd: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, no section header The vfpv3 and /lib/ld-musl-armhf.so.1 confirms to me this is an armhf. See also: https://www.baeldung.com/linux/arm64-armel-armhf-overview My cert: $ openssl x509 -noout -text -in /tmp/x.com/fullchain.pem | grep -A2 Validity Validity Not Before: Apr 10 22:15:43 2023 GMT Not After : Jul 9 22:15:42 2023 GMT ==> I did not get any warning trace on that system with: $ lighttpd -f test.conf -tt using my LE certificates, though that test system has only lighttpd 1.4.67 at the moment. My test system is running a 32-bit kernel. Please confirm you are running an arm64 kernel, as you posted above. What lighttpd package (from which architecture) do you have installed? $ file /usr/sbin/lighttpd might be useful. Please ensure that you have installed the proper package for your architecture. Is your system openssl-based or libressl-based? The only changes between lighttpd 1.4.67 and lighttpd 1.4.69 in lighttpd mod_openssl that seemed to be related to this issue is that lighttpd mod_openssl started using libressl ASN1_TIME_cmp_time_t() when LIBRESSL_VERSION_NUMBER >= 0x306fL and this also requires that lighttpd mod_openssl was built with libressl. The standard Debian package for lighttpd mod_openssl is built with openssl.
Bug#1034586: always reports inactive/expired certificate on armhf
Package: lighttpd Version: 1.4.69-1 Severity: normal I am using the latest openssl and lighttpd packages on an armhf (with an arm64 kernel) and an amd64 system, and only on the armhf system I always get this warning at startup even just after having created a Let's Encrypt certificate. Apr 19 01:23:31 omitted.mi.bofh.it lighttpd[8876]: 2023-04-19 01:23:30: (mod_openssl.c.1335) SSL: inactive/expired X509 certificate '/var/lib/dehydrated/certs/omitted.mi.bofh.it/fullchain.pem' # openssl x509 -noout -text -in /var/lib/dehydrated/certs/bokassa.mi.bofh.it/fullchain.pem | grep -A2 Validity Validity Not Before: Apr 18 22:13:45 2023 GMT Not After : Jul 17 22:13:44 2023 GMT After looking at https://github.com/lighttpd/lighttpd1.4/blob/fdb7ffed88b9dfe09a51e7fb58e5ddfe938c1ec9/src/mod_openssl.c#L1284 I wonder if this is common on all 32 bit systems instead. -- ciao, Marco signature.asc Description: PGP signature
