Certificate Transparency logging delay

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?

Hi @Euclid

CT-logs are the one thing. The other thing are CT-monitors like Google or crt.sh.

crt.sh is sometimes very slow.


What does that mean? What's the domain name?

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.

It's a Chrome problem.

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.

Reference: http://www.certificate-transparency.org/certificate-transparency-in-chrome

Is the core issue that the neither embedded log published the certificate within the Maximum Merge Delay (MMD)?

Which two logs’ SCTs were embedded in the certificates that Chrome refused to verify?

I can only answer the question about the SCT list:

‎Tuesday, ‎21 ‎May, ‎2019 09:24:11

‎Tuesday, ‎21 ‎May, ‎2019 09:24:12

And Google Chrome shows this under Security:

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

1 Like

I will post the log the next time the certificate gets renewed. Right now, I only have production systems with letsencrypt issued certificates.

Sorry, misunderstood something.

The problem

looks really bad.

PS: Your main domain sends a preload header. PPS - no, that's not relevant, your domains isn't preloaded.

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