The messages in your screenshot suggest that your system date might have reset to January 1970.
Have you tried fixing the date in the firmware setup and then rebooting?
Update: I just discovered this thread with more info: Clock reset to 2070-01-01 on February 29 - #5 by joao.azevedo
I appreciate it that you have changed the title into a better description of the problem you where facing 
It is a shame that in 2024 we have already software stacks that cannot handle a leap year correctly. On which planet do the programmers live?
My oldest - self built up - CP/M computersytem maybe 30 years ahead has a clock chip which can together with the BIOS absolutely correct handle all aspects of leap years.
We can only hope that such a piece of buggy software does not run on any important computer systems and servers. Maybe on computers with really critical missions
SO coreboot is not usable on any server systems and non-private computer systems
Well except for
a) it will get fixed, and
b) it may be that the problem only happens if booted on Feb 29 and any well-run server is up almost all of the time, making that event unlikely, particularly if Feb 29 falls on a traditional workday as it did this year. (Data point: Our main server at work has been up for > 500 days.)
I guess, since it’s open source, you could answer your own question.
(The implication of the other linked post is that this might be a regression i.e. used to work and then someone broke it. Again, since it’s open source, you may be able to find out what the change was and verify that.)
For example: Why not 30 years old an well documented leap year code as an starting point from programming a functional leap year routine in Coreboot?
I am very surprised that things, solved 30 years ago come up in 2024 on such simple things as a leap year routine.
If there is a mission critical server, You can hardly count on such things like coreboot.
What do with such a server when it is started up on 29.2.2024? Sent all people home which are affected by such?
Bugs will ever occure, no question. But here I can only shake my heads about…
You can set date manually in the shell:
date -s "2024-03-01"
hwclock -w
poweroff
And then start the machine again, it should be fixed. Also you can upgrade your Coreboot which will change default datetime so clock resets will not cause booting problems anymore.
I know this. But the screen above looks like the system could not boot with the wrong date?
Sorry I wanted to reply to the OP.
Yes, the date was reset to a past, probably to 1970-01-01. This is representation of unix timestamp with value of 0. That is why the system thinks that “key … was created … days in the future”. New firmware uses year 2070 as the default value, so if a reset happens (for example unplugged battery and empty CMOS battery) then it will boot OK.