Creation of certificates with validity dates beyond the 32-bit limit are truncated to the edge. Example from 8.4p1: [user@disp8853 ~]$ ssh-keygen -t ecdsa -N "" -q -f ca [user@disp8853 ~]$ ssh-keygen -t ecdsa -N "" -q -f user [user@disp8853 ~]$ ssh-keygen -s ca -I bug-report -z 911 -n 32bitdates -V always:20390101 user.pub Signed user key user-cert.pub: id "bug-report" serial 911 for 32bitdates valid before 2038-01-19T03:14:07 [user@disp8853 ~]$ ssh -V OpenSSH_8.4p1, OpenSSL 1.1.1k FIPS 25 Mar 2021 This has been observed in several versions from 7.x to 8.x on x86_64 (Windows and Linux), and armv7 (Linux)
It looks like the cert validity is fine, it's the formatting function that has the limit: if (cert->valid_after != 0) { /* XXX revisit INT_MAX in 2038 :) */ tt = cert->valid_after > INT_MAX ? INT_MAX : cert->valid_after; tm = localtime(&tt); strftime(from, sizeof(from), "%Y-%m-%dT%H:%M:%S", tm); } Unfortunately there's no TIME_T_MAX, and while we can figure out how big time_t is but there's nothing specifying whether it's signed or unsigned. Anyway there's a format_absolute_time in misc.c, we should factor these out of sshkey.c and fix it in format_absolute_time.
Created attachment 3531 [details] allow formatting dates >INT_MAX This patch ought to fix it on platforms with 64bit time_t, although it'll also require some work in configure to be correct on other systems.
Created attachment 3532 [details] allow formatting dates >INT_MAX
That makes a lot more sense. I'm not a C programmer by any means, but I saw uint64 in the cert creation code and the protocol spec and was baffled by this output from ssh-keygen. Thanks for finding the root cause!
The fixes have gone in and will be in the next major release. Thanks for the report. https://github.com/openssh/openssh-portable/commit/6c29b387cd64a57b0ec8ae7d2c8d02789d88fcc3 and https://github.com/openssh/openssh-portable/commit/f5fc6a4c3404bbf65c21ca6361853b33d78aa87e
closing bugs resolved before openssh-8.9