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: WontFix
Last visit > 30 days ago
Closed: Oct 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Sign in to add a comment

Certificate Transparency - GDCA CT Log Server Inclusion

Reported by, Mar 29 2016 Back to list

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Steps to reproduce the problem:
Log Server URL:
HTTPS supported: yes
MMD: 24 hours

Contact Information:
- email:;
- phone number:  +86(20)83487228-805
- Log Operator: Wang Shengnan

Server public key: Attached file: gdca-ct-key-public.pem
Accepted Roots: Attached file: gdca-trusted-roots.pem

the "Merge Delay Monitor Root" already add in the trusted roots file.

Log Description and Policy: Currently, the only policy in place is that the certificate chain to a publicly trusted root certificate.  However, during the testing and log inclusion process, we are only including the GDCA trusted roots as authorized. Additional root entries will be evaluated after receiving an inclusion request. We will likely develop our policies further based on the results from the discussions in the Trans working group and our own internal policies.  Such policies may include an enforcement of BR and EV standards, a requirement for at least organizational vetting on the certificate, minimum key sizes and hash algorithms, and similar checks.

What is the expected behavior?

What went wrong?
The GDCA CT Log Server is ready to be included in the Chrome and Chromium browsers.

Did this work before? N/A 

Chrome version: 49.0.2623.87  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 21.0 r0
178 bytes Download
3.0 KB Download
Components: Internals>Network>SSL Internals>Network>CertTrans
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Status: Untriaged (was: Unconfirmed)
(Moving to Untriaged as per net triage instructions to get it off triager's radar screens.)

Comment 3 by, Mar 29 2016

(assigning to myself for so it's not lost)
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 July 6 2016 and we will update this bug shortly after that date to confirm.
4.0 KB Download
Update the file to the same as the one on the log server. Thank you!

Comment 7 by, Jul 8 2016

 Issue 594441  has been merged into this issue.

Comment 8 by, Jul 8 2016

Status: Assigned (was: Untriaged)

Comment 9 by, Jul 12 2016

Unfortunately, it appears that the log server did not have sufficient availability, having 98.756% of reachability probes successful (with the policy requiring at least 99%, which allows for 21 hours and 36 minutes of unavailability in the 90 days monitoring period).

To re-apply, you would need to clear the log and change the keys (in essence, a new log).
Hello, I have some doubts.
First of all, We monitor our log every minutes and the log have 99.50% uptime. Our log also have 99.41% uptime from other CT monitor( 
Can you tell us how the percent of availability is calculated?
We will check our log and clear the log. Then we plan to re-apply later. Can we re-apply in this issue or create a new one ?

Comment 12 by, Jul 20 2016

You should re-apply in a new issue.
You should also change the log key, so it's effectively a new log.
I recommend a new URL for the new log - it does not have to be a new domain, so you could use or something similar.

Please CC me directly on the new inclusion request so we don't have to wait for it to be triaged. 
OK.Thank you.

Comment 14 by, Jul 21 2016

The frequency of our monitoring is variable, averaging about every two minutes. The availability is calculated as a ratio of successful probes over the total number of probes.

It is possible that a similar amount of unavailability could result in a lower percentage with a lower frequency. For example, your monitoring is done every minute, and had 0.5% of unavailability, the same number of failed probes with a 2 minute frequency would result in 1% of unavailability. In an extreme case, if we did a single probe per day, only one of them failing would immediately bring the availability below 99%!

We are looking into ways to improve our compliance monitoring system at the moment, but for now, we are applying the same methodology to every logs.

Comment 16 Deleted

We had re-applied in a new issue. here is the link to the issue:
Labels: -OS-Windows -Type-Bug Type-Feature
Status: WontFix (was: Assigned)

Sign in to add a comment