https://www.gstatic.com/ct/log_list/log_list.json stopped working

147 views
Skip to first unread message

SriRamji Kathiravan

unread,
Jun 1, 2020, 12:24:00 PM6/1/20
to certificate-transparency
Certificate transparency stopped working for s3.amasonaws.com while debugging it was working fine with version 2 log_list but not working on version 1 log_list
We are ready get rid of old version but it does affecting our production user

Please revert if any changes made recently in version 1 log_list(this was working fine in recent days, today it stopped working)

Thank you understanding

Al Cutter

unread,
Jun 1, 2020, 12:39:48 PM6/1/20
to certificate-...@googlegroups.com, google-ct-logs
Hi SriRamji,

could you provide a little more detail on exactly what you're seeing?
It might help folks figure out what the problem might be.

Kind regards,
Al.


--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/certificate-transparency/da316b03-75db-4c00-a741-68181cde2d41%40googlegroups.com.

SriRamji Kathiravan

unread,
Jun 1, 2020, 10:12:27 PM6/1/20
to certificate-transparency
Hi Al

We have validated "s3.amazonaws.com" domain in 2 log_list version

CASE 1 -

Error - Certificate transparency failed due to only one SCT matched(we expect at least 2 SCT should match, like in ios https://support.apple.com/en-us/HT205280).

CASE 2 -

Success- Certificate transparency passed with 2 SCT matching.



On Monday, June 1, 2020 at 10:09:48 PM UTC+5:30, Al Cutter wrote:
Hi SriRamji,

could you provide a little more detail on exactly what you're seeing?
It might help folks figure out what the problem might be.

Kind regards,
Al.


On Mon, Jun 1, 2020 at 5:24 PM SriRamji Kathiravan <sriramji....@pearson.com> wrote:
Certificate transparency stopped working for s3.amasonaws.com while debugging it was working fine with version 2 log_list but not working on version 1 log_list
We are ready get rid of old version but it does affecting our production user

Please revert if any changes made recently in version 1 log_list(this was working fine in recent days, today it stopped working)

Thank you understanding

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.

SriRamji Kathiravan

unread,
Jun 1, 2020, 11:14:57 PM6/1/20
to certificate-transparency
More specific error - Failure: Too few trusted SCTs, required 2, found 1 in {u9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YU==Valid SCT, h3W/51l8+IxDmV+9827/Vo1HVjb/SrVgwbTq/16ggw8==SCT timestamp, 1573258714144, is greater than the log server validity, 1588550440.}

Alex Cohn

unread,
Jun 2, 2020, 12:06:25 AM6/2/20
to certificate-...@googlegroups.com
The "log server validity" timestamp, 1588550440, in your error indicates corresponds to 2020-05-04 at 00:00:00 UTC, which is the DigiCert 2 log's retired timestamp. The DigiCert 2 SCT embedded in the current s3.amazonaws.com cert (https://crt.sh/?id=2121653818) is timestamped 2019-11-09 00:18:34.144 UTC, which corresponds to the 1573258714144 SCT timestamp. One of these timestamps is in seconds and the other in milliseconds since the UNIX epoch. 2020-05-04 is after 2019-11-09, but 1588550440 is less than 1573258714144.

Are you using a homegrown CT implementation? If so, does it account for seconds/milliseconds when determining if a SCT is from a retired log?

To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/certificate-transparency/80b37171-6ecf-4370-9850-54383892f833%40googlegroups.com.

SriRamji Kathiravan

unread,
Jun 2, 2020, 1:53:32 AM6/2/20
to certificate-transparency
We are using https://github.com/babylonhealth/certificate-transparency-android version 1.4, this(seconds/milliseconds variation) was not handled in the library

To avoid confusion/maintain consistency between timestamp, Is this possible to update the log_list timestamp value in milliseconds?


ct-timestamp-issue.png



To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.

Al Cutter

unread,
Jun 2, 2020, 7:27:17 AM6/2/20
to certificate-...@googlegroups.com
On Tue, Jun 2, 2020 at 6:53 AM SriRamji Kathiravan <sriramji....@pearson.com> wrote:
We are using https://github.com/babylonhealth/certificate-transparency-android version 1.4, this(seconds/milliseconds variation) was not handled in the library

To avoid confusion/maintain consistency between timestamp, Is this possible to update the log_list timestamp value in milliseconds?

Changing the unit of a field definition in a config file which has been around for a while seems like it might more generally make things worse.
However, the new log_list v2 schema, which I believe folks should be moving to, seems quite clear that temporal periods etc. are all defined as JSON date-time types - hopefully this will help avoid confusion in the future.

I see that you've opened an issue on Babylon Health's CT repo (https://github.com/babylonhealth/certificate-transparency-android/issues/40 for anyone else following along), let us know if there's anything else we can do to help.
 


image.png




To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/certificate-transparency/670d2d87-1dcb-4b18-a2f2-478bd230a939%40googlegroups.com.

Matt Dolan

unread,
Jun 2, 2020, 9:43:20 AM6/2/20
to certificate-...@googlegroups.com

The documentation on the format of the v1 schema was somewhat lacking, and indeed the original schema just has it down as a number, so we clearly made a mistake in the interpretation.

 

The library no longer supports the v1 schema, as Al mentions the v2 schema is much better defined, so please upgrade to the latest version of the library, v0.2.0 which should fix your issue.

 

 

From: 'Al Cutter' via certificate-transparency <certificate-...@googlegroups.com>
Reply to: "certificate-...@googlegroups.com" <certificate-...@googlegroups.com>
Date: Tuesday, 2 June 2020 at 12:27
To: "certificate-...@googlegroups.com" <certificate-...@googlegroups.com>
Subject: Re: https://www.gstatic.com/ct/log_list/log_list.json stopped working

 

On Tue, Jun 2, 2020 at 6:53 AM SriRamji Kathiravan <sriramji....@pearson.com> wrote:

We are using https://github.com/babylonhealth/certificate-transparency-android version 1.4, this(seconds/milliseconds variation) was not handled in the library

 

To avoid confusion/maintain consistency between timestamp, Is this possible to update the log_list timestamp value in milliseconds?

 

Changing the unit of a field definition in a config file which has been around for a while seems like it might more generally make things worse.

However, the new log_list v2 schema, which I believe folks should be moving to, seems quite clear that temporal periods etc. are all defined as JSON date-time types - hopefully this will help avoid confusion in the future.

 

I see that you've opened an issue on Babylon Health's CT repo (https://github.com/babylonhealth/certificate-transparency-android/issues/40 for anyone else following along), let us know if there's anything else we can do to help.

 

 

 

Reply all
Reply to author
Forward
0 new messages