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.

Read

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

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:

v1
e2694bae26e8e94009e8861bb63b83d43ee7fe7488fba48f2893019dddf1dbfe
‎Tuesday, ‎21 ‎May, ‎2019 09:24:11
SHA256
ECDSA
304402202ee737c199dbc5e29fad9decc7d6e434d7c8111c3577ab175447db08251ad68b0220346b5baad8d588be3edbcd9ebd10fbc6014e5e9082df47f224de2004caafc6f8

v1
293c519654c83965baaa50fc5807d4b76fbf587a2972dca4c30cf4e54547f478
‎Tuesday, ‎21 ‎May, ‎2019 09:24:12
SHA256
ECDSA
30440220682b5b3c5a5bbef8a020d5fea1bb956f9aec481bac54e015305c989b68be27470220694def1e367bb661d120f52e09241ab06a31cdd13ad5caa0a4f73cf4c80cedbc

And Google Chrome shows this under Security:

Certificate Transparency
SCT
DigiCert Yeti2019 Log (Embedded in certificate, Verified)
SCT
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.