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.
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.
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.
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.
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.
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.