Year 2038 bug on LibreSSL 32bit regression between 2.2.x and 2.3.x

[FrNico]

Since version 2.3.x (noticed that first when LibreELEC bumped version in April 2016), LibreSSL has a Year 2038 problem with certificate verification, to validate notAfter field, it used to work fine with version that LibreELEC was using before that update (below example with 2.2.6): LibreELEC/LibreELEC.tv#204

Tests on 2.3.x:

$ cat /etc/release
RPi2.arm-devel-20160704210656-#704-g822942e
$ uname -a
Linux kodi-rpi-1 4.7.0-rc6 #1 SMP Mon Jul 4 21:08:01 BST 2016 armv7l GNU/Linux
$ cd /usr/share/ca-certificates/mozilla
$ openssl version
LibreSSL 2.3.5
$ openssl x509 -dates -in GeoTrust_Primary_Certification_Authority_-G2.crt|grep notAfter
notAfter=Jan 18 23:59:59 2038 GMT
$ openssl verify GeoTrust_Primary_Certification_Authority-G2.crt
GeoTrust_Primary_Certification_Authority-_G2.crt: OK
$ openssl x509 -dates -in StartCom_Certification_Authority_G2.crt|grep notAfter
notAfter=Dec 31 23:59:01 2039 GMT
$ openssl verify StartCom_Certification_Authority_G2.crt
StartCom_Certification_Authority_G2.crt: C = IL, O = StartCom Ltd., CN = StartCom Certification Authority G2
error 14 at 0 depth lookup:format error in certificate's notAfter field

Tests on 2.6.x:

$ openssl version
LibreSSL 2.2.6
$ cat /etc/release
RPi2.arm-7.0.2
$ uname -a
Linux kodi-rpi-1 4.4.13 #1 SMP Sat Jun 25 04:53:00 BST 2016 armv7l GNU/Linux
$ openssl verify StartCom_Certification_Authority_G2.crt
StartCom_Certification_Authority_G2.crt: OK

[bob-beck]

Does your platform only have a 32 bit time_t? In this case this is working as intended.

Your platform is unable to deal with time_t after Y2038 - and so dealing with certificates
after such a date is dangerous. LibreSSL defensively fails if time_t can not represent these times. So the safe thing is to actually fail.

You need to actually fix this at the operating system level.

[4a6f656c]

FTR this was address by clamping the notafter date to 2038 in the case of a 32-bit time_t (see libressl/openbsd@362ffef)