because CT logs doesn't backdate if clock is skewed it will still error out with ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, and if it will error out anyway cert not yet valid would be much more clearer error code than weird CT policy error
well they would still works for implementation that doesn't check CT though
P.S not sure backdating SCT sign a thing as MM delay is just 24 hours so even an hour is big deal for that
4 Likes
I think the "clock skew" that Let's Encrypt mentions is actually about the end user's computer, not Let's Encrypt or CT log servers. They are required to maintain clock sync in their infrastructure.
Certain OS/browser combos freak out if the SCT on the certificate is from the future. It seems a bit silly (bar some misunderstanding of the issue) that the certificate backdating is made ineffective because the SCTs are not backdated as well.
5 Likes
Not all client systems check CT, though, and the point of the backdating is to deal with systems that are already known to be at least a little bit off the beaten path (given that they may have a clock off by up to an hour).
I don't know if backdating by, like, 5 minutes instead, would handle the majority of the cases, or if the hour is needed for systems that need some sort of manual update when daylight savings time happens or something along those lines?
4 Likes
I doubt if there exists any system that is modern enough to support state-of-the-art cryptography but still cannot not handle summer time.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.