A newly issued certificate from "Let’s Encrypt Authority X3 " does not show up on https://crt.sh/ and it is also not in the Google Certificate Transparency Report. However, there seems to be a SCT receipt in the certificate itself (SCT List property) and Qualsy’s SSL Server Test also doesn’t complain about the CT error.
It seems there is a significant delay (over 30 minutes) until Google Chrome recognizes that the certificate is present in any CT logs.
Is this a known issue and is this delay documented somewhere?
The main issue seems to be that the CT monitor Google Chrome uses is slow. Meaning, Google Chrome displayed a NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED error for over 30 minutes. Meaning, the website was not accessible to any Google Chrome users for this time. The domain is www.smartftp.com
More research needs to be done why Google Chrome couldn’t use the embedded certificate SCT list to figure out that the certificate is indeed valid and logged.
If a website has it’s first certificate, that may be a problem.
What do you mean by that? There were many certificates issued by “Let’s Encrypt Authority X3” for this particular domain before.
Without further investigations it is not possible to say what causes the issue. I have seen the same problem before and I’m wondering why nobody has noticed or reported it. It is a quite severe issue in my opinion (website inaccessible to all Chrome users for 30 minutes).
I have found some documentation on how Chrome does Certificate inclusion checks:
Chrome may check that an SCT has been honoured by the CT log that issued it, i.e. that the corresponding certificate is indeed published in that CT log. This is so that a CT log cannot issue an SCT but then never publish the certificate, thereby hiding its existence. Chrome does this by sending a specially-crafted DNS query that requests an inclusion proof from the log. Using DNS allows the user to remain anonymous from the CT log’s perspective and enables caching of inclusion proofs. If the log cannot provide a proof, or the proof cannot be verified, then Chrome learns that the log has misbehaved.
DigiCert Yeti2019 Log (Embedded in certificate, Verified)
Google ‘Icarus’ log (Embedded in certificate, Verified)
Show full details
This request complies with Chrome’s Certificate Transparency policy.
So maybe it was not published yet, or the “special” DNS query (to validate the inclusion) failed for other reasons.
It’d be interesting if you could upload an export from chrome://net-export/ for a session where you encounter this problem. It’d reveal if the issue was maybe the Google Service that is used to perform the CT DNS query.
I tried to coax my Chromium into forcing the CertificateTransparencyLogAuditing feature to be enabled, but didn’t succeed. Without that, my Chromium only performs the offline SCT checks.