[outcave]

and then I remain screwed ....

Yes, I'm afraid so. It's much harder for Linux to change to 64-bit time_t on 32-bit platforms, as detailed here. The LibreSSL developers have a history of using and supporting OpenBSD which (for various reasons outlined in the LWN article) has already made the jump to 64-bit time_t everywhere, so I understand their attitude although I may not agree with it. Perhaps switching to LibreSSL was a bad idea if this is how they're going to act going forward, as it's pretty much a "fsck you" to (32-bit ABI) Linux.

In the meantime, the certificate authority industry should be mindful of this issue, and I'm sure many already are, and simply avoid issuing certificates with expiry dates after 2038 until there is a solution that supports Linux. I would suggest you contact Hide.me and discuss the issue with them, perhaps they have an alternative certificate you could use.

Hi again.
I don't think the certificate authority industry should be mindful of this issue, the problem is LibreSSL, OpenSSL works fine!
Hide.me answered to me that the certificate date problem is on LibreSSL and not with OpenSSL or with PolarSSL.
They "fully support only the official OpenVPN community distribution and that one is supposed to be linked with OpenSSL or PolarSSL ( mBed TLS ), not LibreSSL. The say more: "In OpenSSL, versions above 1.0.0, this bug is fixed and 32bit machines/OSes may validate any date constraint. OpenSSL uses it's own date routines and does not depend on the OS".

Then, they will not reissue a new certificate beacuse of LibreSSL...
Well, I think Hide.me right, it's not their problem and they are right the other that issue certificate with date more then 2038.

I do not want to debate, but why LibreELEC choose to use LibreSSL instead on the "classic" OpenSSL?
May be the word "LIBRE" is more fashionable then "OPEN"?

Anyway, to summurize, LibreSSL on 32bit OS (such as Raspberry Pi, Raspberry Pi 2, and so on...) will not support Certificates issued with date more then 2038, it seem that they are not interested to solve the issue, so the problem will remain in LibreELEC.

I hope and I expect the LibreELEC community/devolopers will seriously evaluete this problem/limitation and will move again to OpenSSL.

Thanks!