The imported certificate's Days Valid field is displaying wrong value -- it is showing 6090 days for a certificate which has 36524 days validity (100 years).

The reason for this seems to be the date handling in the OS caused by using 32-bit Unix time_t structure (a.k.a. the Year 2038 Problem) -- the Invalid After field for the certificate in question is showing Jan/01/2038 12:47:58 when it should be showing Apr/30/2121 12:47:58.

The easiest solution is to upgrade to Linux kernel 5.6 and glibc-2.32 or higher where 32-bit apps can use 64-bit time_t just by recompiling. Additional details about full userspace support for 64-bit time_t and other ways of handling this if you are using syscalls directly are available here.

Note that your using of 32-bit time_t is certainly affecting other functions as well, not just certificate validity checks.

Switch to 7.1beta5 and enjoy that 64 bit time.

Let me also add that for a certificate created today with 3652 days it is showing Days Valid as 3652, but it shows Expires After as 3636 days, so there seems to be more wrong than just 32-bit cutoff. I found a discussion about that here and after reading it I still don't understand where this error is coming from (RouterOS or WinBox). Regardless, it should be fixed.

Switch to 7.1beta5 and enjoy that 64 bit time.

Are you seriously suggesting to use beta software in production environment?!? o.0

Oh, in production you don't use certificates valid for 100 years.
Problem solved.

Oh, in production you don't use certificates valid for 100 years.
Problem solved.

+1000

There appears to still be some problems with this.
As a test I created a certificate (on a PC) with an expiration set to the max allowed by the RFC (99991231235959Z).
This shows as much much less than year 9999.

There appears to still be some problems with this.

I drove my family sedan on German Autobahn on section without speed limit and I wanted to go 1500 kph. Even if I pushed pedal to the metal, it wouldn't go faster than 190 kph. And yet speedometer goes up to 240 kph. There's definitely a problem with this.


The whole world is moving towards short-lived SSL certificates (LetsEncrypt hands out certificates with validity of 90 days since very beginning, all the rest are now on sub-year periods), and yet you're complaining that validity of 7977 years doesn't work correctly? Get serious, will you? Even if you install certificate with validity in 2038, you'll very probably have other problens with your device ... sooner. The way things are moving, RSA keys (and possibly current ED keys as well) will be obsolete before 2038 and you'll have to install another certificate because of that.

It's not just long validity. I need only one month, but since it's for my little time travelling project (sorry, can't say more, top secret), it needs to be in 9999. But even latest RouterOS 7.7beta8 doesn't like it, doesn't show any dates and expiration shows ~19k days and counting up. This clearly needs to be fixed, before "RouterOS, not ready for the future" becomes new motto.

But seriously, it should be fixed if RFC allows it, even if it's not pressing matter.