|Issue 598526||Certificate Transparency - GDCA CT Log Server Inclusion|
|Starred by 3 users||Reported by hanjie77...@gmail.com, Mar 29 2016||Back to list|
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://ct.gdca.com.cn/ct/v1 HTTPS supported: yes MMD: 24 hours Contact Information: - email: firstname.lastname@example.org; - 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
Mar 29 2016,
Mar 29 2016,
(Moving to Untriaged as per net triage instructions to get it off triager's radar screens.)
Mar 29 2016,
(assigning to myself for so it's not lost)
Apr 7 2016,
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.
Apr 8 2016,
Apr 8 2016,
Update the file to the same as the one on the log server. Thank you!
Issue 594441 has been merged into this issue.
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(https://ct.grahamedgecombe.com/). 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 ?
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 https://ct.gdca.com.cn/new_log/ct/v1 or something similar. Please CC me directly on the new inclusion request so we don't have to wait for it to be triaged.
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.
We had re-applied in a new issue. here is the link to the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=654306
|► Sign in to add a comment|