Google v3 frozen log list crossed 70-day freshness limit, causing Android CT checks to fail closed

[CMWR421]

Apps using certificatetransparency-android via Android/OkHttp are now receiving Google's frozen third-party CT log list:

curl -I -A 'okhttp/4.12.0' https://www.gstatic.com/ct/log_list/v3/log_list.zip

Response includes:

x-ct-log-list-variant: v3-frozen
last-modified: Fri, 03 Apr 2026 23:28:00 GMT

The JSON contains:

{
  "version": "DO NOT USE THIS LOG LIST. See https://googlechrome.github.io/CertificateTransparency/apps_3p_libraries.html",
  "log_list_timestamp": "2026-04-01T00:00:00Z"
}

The live/browser variant still has a recent timestamp:

curl -I -A 'Mozilla/5.0' https://www.gstatic.com/ct/log_list/v3/log_list.zip

x-ct-log-list-variant: v3-live

Its JSON has:

{
  "log_list_timestamp": "2026-06-09T13:40:09Z"
}

Because LogListCacheManagementDataSource treats network log lists older than 70 days as LogListStaleNetwork, the frozen list crossed that threshold on 2026-06-10 UTC:

private val SEVENTY_DAYS = Duration.ofMillis(6048000000)

On Android API 30 with Appmattus installed as the default CT provider, normal HTTPS requests fail closed:

javax.net.ssl.SSLHandshakeException: Certificate transparency failed
Caused by: java.security.cert.CertificateException: Certificate transparency failed
  at CertificateTransparencyTrustManagerExtended.checkServerTrusted

A control test on the same emulator with the Appmattus provider disabled allows the same HTTPS requests to complete normally.

This appears related to Google intentionally serving frozen CT lists to third-party CT libraries:
https://googlechrome.github.io/CertificateTransparency/apps_3p_libraries.html

---

Related: #163 #143

[antonielhayek]

This is urgent happening for several hours. Is there any quick fix or workaround other than failOnError = { false } ?

[CMWR421]

@antonielhayek we ended up taking the red pill and disabled CT for <16 altogether... (already implemented native platform support for >=16 but been keeping this lib for the non-supported versions)

quick workaround can be patching the library on your end to remove that SEVENTY_DAYS magic number... make it TWO_THOUSAND_SEVENTY_DAYS instead... but this will require a native release so your users will stay impacted till the release goes out and they update...

since the timestamp is coming from google's servers they need to update frozen log list's timestamp, which I don't think is a sane expectation considering they want to kill this lib with fire.............

even if they update right now, it'll take some time to invalidate their cache... we've had this problem in #143 as well :'D

[gajrajchouhanprocore]

@antonielhayek @CMWR421 can we use For devices running Android versions below 16, we can disable the timestamp checks to fail safely:
LogListResult.DisableChecks(timestamp, networkResult)
For devices running Android 16 and above, we will use Android's native certificate transparency implementation and avoid using the certificatetransparency library.

[antonielhayek]

it seems to be working again now. What happened exactly? @CMWR421

[jdeblasio]

Please see https://groups.google.com/a/chromium.org/g/ct-policy/c/qY3aOKr5-sU/m/bOm8_RNyAwAJ

[dineshvg]

we also ended up taking the red pill and disabled CT for <16 altogether.