New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Verified
Last visit 17 days ago
Closed: Aug 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature

Sign in to add a comment

Certificate Transparency - WoSign CT log server inclusion request

Reported by, Apr 21 2016

Issue description

Contact Information:
- email:;
- phone number:  +86-755-8600 8688
- Log Operator: Richard Wang, Jeff Tang, Dong Liang

Log Server URL:

Server public key: Attached file: ws-ctlog-key-public.pem

This log server is operated by WoSign ( This log server will act as a public log server that it will include all trusted root by Mozilla for free. 
WoSign will log all issued SSL certificates in this log server.

MMD: 24 hours

Accepted Roots: Attached file: ws-ctlog-trusted-roots.pem

What is the expected behavior? 

What went wrong? N/A 

Did this work before? 

Chrome version: 44.0.2403.89  Channel: n/a
OS Version: 
Flash Version:

178 bytes Download
273 KB Download
Components: Internals>Network
Components: -Internals>Network Internals>Network>CertTrans
Status: Untriaged (was: Unconfirmed)
Labels: -Type-Bug Type-Feature
Status: Started (was: Untriaged)
Thank you for your request, we have started monitoring your log server. Should no issues be detected, the initial compliance monitoring phase will be complete on 2nd August 2016 and we will update this bug shortly after that date to confirm.
This log has passed the initial 90 day compliance period and we will start
the process to add this to Chrome.

Comment 7 by, Aug 5 2016

I'm had massive trouble downloading certificates from this log.  Does the testing include the ability to call get-entries?
I too have had massive trouble with this log.  From some network vantage points the log is usable (barely), but from two vantage points in particular, get-sth regularly takes 5-10 seconds and large get-entries calls time out.  Unfortunately, my primary log monitor is at one of those vantage points, so it's going to be a real headache for me to monitor this log.

Comment 9 Deleted

About the long time cost to request to WoSign’s log, I think this is because our log is deploying in Beijing. Currently, almost all log is deploying in American except Izenpe , CNNIC, and WoSign’s log. I think logs which deploy outside American can provide more chooses and in fact increase the CT environmental diversity.
About mentions about “get-sth” request will cost 5-10 seconds, I had test it in, and most request was finished below 3 seconds and some long time cost on DNS, maybe you can try this.
And about get-entries large download cause timeout, we are consider to change the max certificates return amount per request from 1000 to 100, although this change will split one request to ten requests and in fact it increase total download times. But In some CT client implements , client just raise an error and exit when meet an timeout error, this change can reduce the frequency of this kind of exit.

I agree that it's good to deploy logs outside America, and I understand that latency is going to be higher when contacting logs that are overseas from the United States.  The problem in this case isn't that WoSign's log is in China.  Instead, the problem is that the peering between China Telecom and Level 3 is bad.  I get 30% packet loss when pinging from and  According to China Telecom's looking glass[1], the route from Beijing to these two IP addresses goes via Level 3.  From other locations on the Internet I don't see any packet loss to  Those routes don't use Level 3.

It looks like China Telecom is your ISP.  Could you ask them to investigate their peering with Level 3?  (My ISP for (AWS) is already preferring NTT over Level 3 for routes *to* China Telecom, so there's nothing I can do on my end.)


Comment 12 by, Aug 22 2016

I think our CT log server passed the test, could you advise when it will be included in which version Chrome? thanks.
The change to include it ( is awaiting review. So long as that happens in the next few days (it should), it should be included in the next version of Chrome.
Project Member

Comment 14 by, Aug 25 2016

The following revision refers to this bug:

commit 64cb9e2a71c89e801d45dc2cb1476305910851f3
Author: robpercival <>
Date: Thu Aug 25 09:55:14 2016

Adds WoSign log to CT logs list

It has recently completed its 90d compliance monitoring period.

BUG= 605415 

Cr-Commit-Position: refs/heads/master@{#414378}


Labels: M-54
Status: Verified (was: Started)
We are about to add (within the next 72 hours) the "GDCA TrustAUTH R5 ROOT"  root to the list of accepted roots of the WoSign CT log server.

Project Member

Comment 17 by, Feb 13

The following revision refers to this bug:

commit 3cba7db7bd2364806586dd386180fd0129f2ea9a
Author: Rob Percival <>
Date: Tue Feb 13 20:35:35 2018

Set disqualification date for Wosign and StartCom CT logs


Bug:  605415 ,  611672 
Change-Id: I102fa71d98cdeceff5ec723d7a8900ea4b3ea9a9
Commit-Queue: Ryan Sleevi <>
Reviewed-by: Ryan Sleevi <>
Cr-Commit-Position: refs/heads/master@{#536453}

Sign in to add a comment