Description of problem: When specifying a validity interval when signing a certificate using -V option, an hour is added if the system timezone is in Daylight Saving Time (DST). Version-Release number of selected component (if applicable): openssh-8.7p1-8.el9 How reproducible: Always Steps to Reproduce: 1. Grant access on July 28 2022 from 10:00 to 12:00hs: ~~~ [root@rhel9server ~]# ssh-keygen -s ssh_ca -I myuser -n myuser -V 202207281000:202207281200 .ssh/id_rsa.pub Signed user key .ssh/id_rsa-cert.pub: id "myuser" serial 0 for myuser valid from 2022-07-28T11:00:00 to 2022-07-28T13:00:00 ~~~ Actual results: The previous output says "valid from 2022-07-28T11:00:00 to 2022-07-28T13:00:00" instead of "valid from 2022-07-28T10:00:00 to 2022-07-28T12:00:00". ~~~ [root@rhel9server ~]# ssh-keygen -Lf .ssh/id_rsa-cert.pub .ssh/id_rsa-cert.pub: Type: ssh-rsa-cert-v01@openssh.com user certificate Public key: RSA-CERT SHA256:P8r+Z3Hiir9KIg/D04vNwlr9zAYw1k6b6xEeZbF0fps Signing CA: RSA SHA256:0GHrCSlevbRxJCe6/+XzSXx6qzWGre4S0kfrP9R+AcA (using rsa-sha2-512) Key ID: "myuser" Serial: 0 Valid: from 2022-07-28T11:00:00 to 2022-07-28T13:00:00 Principals: myuser Critical Options: (none) Extensions: permit-X11-forwarding permit-agent-forwarding permit-port-forwarding permit-pty permit-user-rc ~~~ Expected results: 1. Grant access on July 28 2022 from 10:00 to 12:00hs (not from 11:00 to 13:00hs): ~~~ [root@rhel9server ~]# ssh-keygen -s ssh_ca -I myuser -n myuser -V 202207281000:202207281200 .ssh/id_rsa.pub Signed user key .ssh/id_rsa-cert.pub: id "myuser" serial 0 for myuser valid from 2022-07-28T10:00:00 to 2022-07-28T12:00:00 ~~~ Additional info: This only happens when the system clock is in DST. When DST finishes( for example in November for Europe/Brussels timezone), there isn´t an hour added: ~~~ [root@rhel9server ~]# ssh-keygen -s ssh_ca -I myuser -n myuser -V 202211281000:202211281200 .ssh/id_rsa.pub Signed user key .ssh/id_rsa-cert.pub: id "myuser" serial 0 for myuser valid from 2022-11-28T10:00:00 to 2022-11-28T12:00:00 ~~~ Description of problem: When specifying a validity interval when signing a certificate using -V option, an hour is added if the system timezone is in Daylight Saving Time (DST). Version-Release number of selected component (if applicable): openssh-8.7p1-8.el9 How reproducible: Always Steps to Reproduce: 1. Grant access on July 28 2022 from 10:00 to 12:00hs: ~~~ [root@rhel9server ~]# ssh-keygen -s ssh_ca -I myuser -n myuser -V 202207281000:202207281200 .ssh/id_rsa.pub Signed user key .ssh/id_rsa-cert.pub: id "myuser" serial 0 for myuser valid from 2022-07-28T11:00:00 to 2022-07-28T13:00:00 ~~~ Actual results: The previous output says "valid from 2022-07-28T11:00:00 to 2022-07-28T13:00:00" instead of "valid from 2022-07-28T10:00:00 to 2022-07-28T12:00:00". ~~~ [root@rhel9server ~]# ssh-keygen -Lf .ssh/id_rsa-cert.pub .ssh/id_rsa-cert.pub: Type: ssh-rsa-cert-v01@openssh.com user certificate Public key: RSA-CERT SHA256:P8r+Z3Hiir9KIg/D04vNwlr9zAYw1k6b6xEeZbF0fps Signing CA: RSA SHA256:0GHrCSlevbRxJCe6/+XzSXx6qzWGre4S0kfrP9R+AcA (using rsa-sha2-512) Key ID: "myuser" Serial: 0 Valid: from 2022-07-28T11:00:00 to 2022-07-28T13:00:00 Principals: myuser Critical Options: (none) Extensions: permit-X11-forwarding permit-agent-forwarding permit-port-forwarding permit-pty permit-user-rc ~~~ Expected results: 1. Grant access on July 28 2022 from 10:00 to 12:00hs (not from 11:00 to 13:00hs): ~~~ [root@rhel9server ~]# ssh-keygen -s ssh_ca -I myuser -n myuser -V 202207281000:202207281200 .ssh/id_rsa.pub Signed user key .ssh/id_rsa-cert.pub: id "myuser" serial 0 for myuser valid from 2022-07-28T10:00:00 to 2022-07-28T12:00:00 ~~~ Additional info: This only happens when the system clock is in DST. When DST finishes( for example in november for Europe/Brussels timezone), there isn´t an hour added: ~~~ [root@rhel9server ~]# ssh-keygen -s ssh_ca -I myuser -n myuser -V 202211281000:202211281200 .ssh/id_rsa.pub Signed user key .ssh/id_rsa-cert.pub: id "myuser" serial 0 for myuser valid from 2022-11-28T10:00:00 to 2022-11-28T12:00:00 ~~~ Is this behavior expected or is it a bug? Thanks in advance.
It's arguably correct - the validity intervals are defined to operate in the local TZ. That being said, it is potentially surprising. I have been thinking of allowing -V to accept less ambiguous time specifications, specifically: - raw seconds-since-epoch, as hex (0x...) values - exact date/times in the UTC TZ, as "UTCYYYYMMDD[HHMMSS]" Would this help you?
Hi Damien, Thanks for your quick reply. > Would this help you? Yes, exact date/times in the UTC TZ will be very useful.
> exact date/times in the UTC TZ, as "UTCYYYYMMDD[HHMMSS]" Why not use compact ISO-8601 notation? yyyymmdd[Thhmmss]Z Local time would omit the trailing "Z", and no other time zone expressions need be supported. The existing "T"-less Notation would still be supported.
> raw seconds-since-epoch, as hex (0x...) values Also, recommend decimal values for seconds since epoch, prefixed with "@", as grokked by some date(1) implementations.
Created attachment 3611 [details] Implement 'Z' suffix and raw hex seconds-since-epoch This implements the Z suffix and 0x-prefixed hex values for seconds-since-epoch. I didn't go with '@decimal' for the latter as IMO these are mostly intended for interfacing with other tools (inc. tests) and are a bit easier to tell apart from something date/time-shaped and consequently less likely to enter accidentally.
Created attachment 3612 [details] unit test for parse_absolute_time(), including forced UTC conversions Regress test for library function. I should note that the underlying parse_absolute_time() function is used in a few places, so the previous diff updates the manpages for the other places the additional UTC dates can be reached.
Created attachment 3613 [details] fixed: Implement 'Z' suffix and raw hex seconds-since-epoch oops, original diff had a typo. Please review this
These have been committed and will be in OpenSSH 9.1. commit b98a42afb69d60891eb0488935990df6ee571c4d Author: djm@openbsd.org <djm@openbsd.org> Date: Thu Aug 11 01:57:50 2022 +0000 upstream: add some tests for parse_absolute_time(), including cases where it is forced to the UTC timezone. bz3468 ok dtucker OpenBSD-Regress-ID: ea07ca31c2f3847a38df028ca632763ae44e8759 commit ec1ddb72a146fd66d18df9cd423517453a5d8044 Author: djm@openbsd.org <djm@openbsd.org> Date: Thu Aug 11 01:56:51 2022 +0000 upstream: allow certificate validity intervals, sshsig verification times and authorized_keys expiry-time options to accept dates in the UTC time zone in addition to the default of interpreting them in the system time zone. YYYYMMDD and YYMMDDHHMM[SS] dates/times will be interpreted as UTC if suffixed with a 'Z' character. Also allow certificate validity intervals to be specified in raw seconds-since-epoch as hex value, e.g. -V 0x1234:0x4567890. This is intended for use by regress tests and other tools that call ssh-keygen as part of a CA workflow. bz3468 ok dtucker OpenBSD-Commit-ID: 454db1cdffa9fa346aea5211223a2ce0588dfe13
Closing bugs from openssh-9.1 release cycle
OpenSSH 9.3 has been released. Close resolved bugs