Time zone problem with issue date?


#1

Hi,

I ran into this yesterday but I cannot easily reproduce it: my server is located in Europe (GMT+1), but I’m currently in California (PST). When I got the ‘your beta invite is ready’ email, it was evening of Nov 4 in California, early morning Nov 5 in Europe. So I configured my server and then tried the new certificates. Since they were issued on Nov 5 Europe time, my clients in California wouldn’t accept them as it was still Nov 4 PST. I understand this is only a temporary issue that resolves after 1 day max, but with the mandatory renewal every 90 days it still happens too often for my liking - especially with the automated renewal process in effect.
Are you aware of this? Can you predate the certificate?

thanks,
-Christian


#2

My experience has been that certificates are been issued with the not before set to UTC and the timezone is adjusted to be shown in the appropriate timezone by the client.

So for example, I requested a at 2015-11-05T22:51+08:00 and on the certificate I get

    Data:
        Version: 3 (0x2)
        Serial Number:
            01:a9:95:7a:74:d1:d2:37:08:e5:59:a2:93:93:00:1e:2f:a0
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1
        Validity
            Not Before: Nov  5 12:51:00 2015 GMT
            Not After : Feb  3 12:51:00 2016 GMT

But in Firefox where my timezone is set to GMT+8 it shows up like

so as long as the time is correct on the client (regardless of timezone) it should be ok. I think that predating certificates would be a bad idea. But potentially the Let’s Encrypt client could be set up so that when it renews certificates it request the new certificates and then hold on to them for a set time (say 6 hours) before installing them to help deal with clients that have the wrong time.


#3

ok here are the two Android screenshots I managed to take last night. My phone was set to PST and clearly complained about the certificate not yet being valid. Might be something specific to my setup, but I don’t know what.

thanks,
-Christian


#4

… and here’s the other one (1 pic limit…)


#5

I think your bowser is too inept to compare the cert time to the time now in UTC.


#6

@daduke I think the time on your phone is out, not by much maybe about 3 minutes.

It looks like the time the certificate was issued was at 2015-11-05T02:50:00UTC which is 2015-11-04T21:50:00-08:00 (i.e. 21:50 PST) but the screen shots from your phone is at 21:47 and 21:48 (presumably that is PST). So if the time on your phone is out by 3 minutes then the certificate will show as invalid until 3 minutes after it’s been issued.


#7

thanks xotc. I just checked, it’s off by ~1.5 minutes and I did not use the phone the second after installing the certificates (I checked with the laptop first), so I doubt this is what I ran into. I’ll check again when I renew.
@My1: stock Android browser, so it would be a problem.

-Christian


#8

well but it seems like the time was off enough to get the error as @xotc showed.


#9

Actually one other thing I’ve noticed after going through a few certificates is that they all seem to be rounded to the nearest minuet. I don’t know if they are all rounded forward (or some are rounded backwards) but with my certificate I requested it at 12:50:33 UTC but the cert was valid 12:51:00 UTC so 27 seconds later.

27 seconds might not seem like a lot but presumably it could be up to 59 seconds and if the time was correct on your laptop it might have been enough that you would have got the “Certificate is not yet valid” message on your laptop.

Rounding to the nearest minute seems like an odd decision, I wonder if there is someone who can shed some light on that?


#10

or maybe it’s server end time that is off with a bit of time drift in the clock ?


#11

ok I think I know what happened (sorry for the late reply - I’m travelling)

the phone somehow had picked up PST time, but not PST time zone. So when I checked on the phone, its time was ~21:50, but GMT+1, so in fact 9h behind the issue timestamp of the certificate.

Sorry for the noise.

-Christian


#12

Glad to hear it @daduke!

Also as an FYI, Let’s Encrypt does backdate certificates by about an hour, to avoid issues with clocks that are off by a few minutes.


#13

is that even allowed, backdating certs?


#14

Yes, it’s common industry practice, though generally it’s best to keep the backdate period short.