Issued cert date shows GMT-1 instead of GMT

Hello,

Maybe it’s a bit late here and I need to rest a bit but I’m seeing something weird, the issued cert date is GMT-1 and it should be GMT.

Two examples, the first one on production and the second one on staging.

[lux][root:letsencrypt]# LANG=C;date && date -u && ./letsencrypt-auto certonly -c /etc/letsencrypt/t1.dnsip.xyz.ini
Sun Mar 20 02:24:59 CET 2016
Sun Mar 20 01:24:59 UTC 2016
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt certonly -c /etc/letsencrypt/t1.dnsip.xyz.ini

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/t1.dnsip.xyz-0002/fullchain.pem. Your cert
   will expire on 2016-06-18. To obtain a new version of the
   certificate in the future, simply run Let's Encrypt again.
 - If you like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

[lux][root:letsencrypt]# openssl x509 -in /etc/letsencrypt/live/t1.dnsip.xyz-0002/cert.pem -dates -noout
notBefore=Mar 20 00:25:00 2016 GMT
notAfter=Jun 18 00:25:00 2016 GMT

As you can see I issued the cert at Mar 20 01:24:59 2016 UTC (GMT) but the cert shows it was issued at Mar 20 00:25:00 2016 GMT so that is not GMT but GMT-1.

And here a new cert issued against staging server:

[lux][root:letsencrypt]# LANG=C;date && date -u && ./letsencrypt-auto certonly -c /etc/letsencrypt/t2.dnsip.xyz.ini --staging
Sun Mar 20 02:28:03 CET 2016
Sun Mar 20 01:28:03 UTC 2016
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt certonly -c /etc/letsencrypt/t2.dnsip.xyz.ini --staging

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/t2.dnsip.xyz/fullchain.pem. Your cert will
   expire on 2016-06-18. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.
[lux][root:letsencrypt]# openssl x509 -in /etc/letsencrypt/live/t2.dnsip.xyz/cert.pem -dates -noout
notBefore=Mar 20 00:28:00 2016 GMT
notAfter=Jun 18 00:28:00 2016 GMT

The cert was issued at Mar 20 01:28:03 2016 UTC (GMT) and the cert shows it was issued at Mar 20 00:28:00 2016 GMT.

Maybe I’m missing something and I’m seeing ghosts but could someone explain it?.

@jsha, I would appreciate if you could seed some light on this issue.

Thank you in advance.

Cheers,
sahsanu

1 Like

cert dates are a number of seconds since whenever in utc like all computer dates, there is no timezones in dates, just in display

but i suspect them being dated to work 1 hour before issuance is not a flaw but a way to avoid issues if installed on systems where the local admin was not ntp aware or the time was otherwise off

so at first use a client with a slightly slow clock isnt seeing the cert used before its before date

as issue date is no issue if installing certs hours after obtaining them (tradition),
but if issue date is ‘now’ on a server making it live seconds later will have issues with clients who are running a few minutes slow

this is of course a theory, not based on foreknowledge,

1 Like

Hi @gothic.ie,

I understand your point but for me a certificate is valid exactly when it was issued, not before nor after, as you said, maybe is a feature to avoid “problems” on misconfigured clocks on the client side but I would like to know it ;).

Thank you.

Cheers,
sahsanu

my guess is based on most lets encrypt certs going live seconds after being recieved
thus as 50% of clients will be slightly fast and 50% slightly slow

you wouldnt want a cert update to kill 50% of users for up to a few minutes

so setting valid from now-1hour dosnt seem bad
(as the cert dosn’t mention issue date, just when its valid from/to)

1 Like

@gothic.ie is correct. Let’s Encrypt backdates certificates by one hour from the time of issuance, to avoid issues with clock skew.

4 Likes