Renewal: blackout problem when client's time behind server's time

Hi.

I see this as not a bug, but some hickup that better having fixed. If it sounds like a user error (my error), please educate me, thanks!

Today I logged into my server and found an automatic update fail log, so I do the manual upgrade and the script runs smoothly.

However, I just noticed that my machine reports an SSL error (OMG!) After some digging, I found out that the certificate issue has an actual date and time same as timestamp when run certbot update.

My machine is around 2 minutes behind global time, and that’s the reason of error. After I waited for 2 minutes, I can access my website fine.

‎Certification valid from: Thursday, ‎July ‎2, ‎2020 3:48:27 PM
My machine’s time: Thursday, ‎July ‎2, ‎2020 3:46:01 PM (OUCH!)

My IT guy setup my machine like this, I knew it, but never bother to fix the time. However, having it properly synced, I wouldn’t experience this blackout.

I can control my own machine, but I couldn’t control other user’s machine. It would be great if I can set the certificate valid date a little back into the past, or something else that can fix this blackout window.

Thanks for your time!

Hmm. Let’s Encrypt certificates are already backdated, for precisely the reason you describe.

That’s weird. The notBefore date on the certificate should be an hour before the creation time of the certificate.

It has been this way for a long time, and I don’t think it’s changed.

Edit: I just issued a certificate, and:

$ openssl x509 -in /etc/letsencrypt/live/backdatetest.foo.monkas.xyz/cert.pem -noout -dates
notBefore=Jul  2 09:34:34 2020 GMT
notAfter=Sep 30 09:34:34 2020 GMT

(which is one hour in the past, right now GMT is ~10:34).

Perhaps your machine is 62 minutes out of time, rather than 2 minutes? Do you live in a timezone with DST? :stuck_out_tongue:

3 Likes

Hi, _az. Thanks for replying.

My machine time is just 2 minutes behind.

I live in a GMT+7, where the server is located at GMT+8, which logically server time is 1 hr ahead of mine. I made sure server is already configed as a GMT+7 (Digital Ocean / Ubuntu 16). There is no DST in my timezone though.

As of now,

$ date
Thu Jul 2 20:46:30 +07 2020

my local machine: Thu Jul 2, 2020, 20:44:04 +7

Not sure what caused this problem, but I attach this just in case.

1 Like

Hi,

The error message said “certificate transpparency required”, which is a different error than certificate not yet valid (or expired). This means the CT logs this certificate send to is not included in your local browser, which probably means you’ll need to update your browser to fix that issue.

Just BTW: If you masked your domain, at least i can’t help you properly with your certificate issue since i’ll need more information.

4 Likes

Oh, that’s interesting. There have been a number of other threads in the past reporting Chrome SCT issues after renewal, which magically go away on their own.

I wonder if it is actually related to clock skew - somehow it is making the certificate backdating ineffective.

2 Likes

That sounds credible to me. I guess that could be a relevant use case for something that we came up with in the very early days of Certbot and eventually hid: a time delay in between the certificate renewal and certificate deployment steps.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.