Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 654306 Certificate Transparency - GDCA CT Log Server Inclusion
Starred by 3 users Reported by hanjie77...@gmail.com, Oct 10 Back to list
Status: Available
Owner:
Cc:
Components:
NextAction: ----
OS: All
Pri: 2
Type: Bug


Sign in to add a comment
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36

Example URL:

Steps to reproduce the problem:
Log Server URL: https://ctlog.gdca.com.cn/ct/v1
HTTPS supported: yes
MMD: 24 hours

Contact Information:
- email: capoc@gdca.com.cn;
- phone number:  +86(20)83487228-805
- Log Operator: GDCA

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: 52.0.2743.82  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 23.0 r0
 
gdca-ct-public-key.pem
178 bytes Download
gdca-trusted-roots.pem
4.0 KB Download
Labels: TE-NeedsTraigeHelp
Please help to cc eranm@chromium.org and google-ct-logs@googlegroups.com 
Cc: robpercival@chromium.org rsleevi@chromium.org
Components: -Internals>Network Internals>Network>CertTrans
Labels: -OS-Windows -Arch-x86_64 -TE-NeedsTraigeHelp Arch-All OS-All
Owner: eranm@chromium.org
Status: Available
Thanks for the log inclusion request.
Comparing the log key from this issue and the log key for the previous log you've applied for inclusion (the one in https://bugs.chromium.org/p/chromium/issues/detail?id=598526) I note the keys are identical.

Can you confirm you have rotated the log's key? The old and new logs cannot share the same key, as that would lead to uncertainty which issued which SCTs and generally it is not possible to verify correct log operation under these conditions.

You should rotate the log's key and make sure you start a fresh, empty log, without any entries, with the new key.
The log's key is a new one. The file name of the key is the same with the old log, but the content of the file is different.
My bad - I may have mis-compared files when checking the public keys for the previous log and this one.
We had uploaded several entries last day with the new key. Do we have to clear the log ?
Owner: katjoyce@google.com
Cc: eranm@chromium.org
Issue 654264 has been merged into this issue.
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 January 9th 2017 and we will update this bug
shortly after that date to confirm.
No, there is no need to clear the log if it was using the key attached to your request.
Understood. Thank you very much!
The server certificate chain returned by ctlog.gdca.com.cn:443 is very messed up.  Currently it's returning a valid end-entity cert, followed by the wrong EV intermediate cert, followed by another end-entity cert (for mail.gdca.com.cn)!

Please would the representatives of GDCA fix this problem?

$ openssl s_client -connect ctlog.gdca.com.cn:443 -servername ctlog.gdca.com.cn 2>/dev/null | head -n 10
CONNECTED(00000003)
---
Certificate chain
 0 s:/C=CN/ST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/L=\xE4\xBD\x9B\xE5\xB1\xB1\xE5\xB8\x82/jurisdictionC=CN/jurisdictionST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/jurisdictionL=\xE4\xBD\x9B\xE5\xB1\xB1\xE5\xB8\x82/serialNumber=74709895-8/businessCategory=Private/O=\xE6\x95\xB0\xE5\xAE\x89\xE6\x97\xB6\xE4\xBB\xA3\xE7\xA7\x91\xE6\x8A\x80\xE8\x82\xA1\xE4\xBB\xBD\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8/OU=\xE5\xAE\x89\xE5\x85\xA8\xE7\xAE\xA1\xE7\x90\x86\xE9\x83\xA8/CN=ctlog.gdca.com.cn
   i:/C=CN/O=Global Digital Cybersecurity Authority Co., Ltd./CN=GDCA TrustAUTH R4 EV SSL CA
 1 s:/C=CN/O=GUANG DONG CERTIFICATE AUTHORITY CO.,LTD./CN=GDCA TrustAUTH R4 Extended Validation SSL CA
   i:/C=CN/O=GUANG DONG CERTIFICATE AUTHORITY CO.,LTD./CN=GDCA TrustAUTH R5 ROOT
 2 s:/C=CN/ST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/L=\xE4\xBD\x9B\xE5\xB1\xB1\xE5\xB8\x82/jurisdictionC=CN/jurisdictionST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/jurisdictionL=\xE4\xBD\x9B\xE5\xB1\xB1\xE5\xB8\x82/serialNumber=74709895-8/businessCategory=Private/O=\xE6\x95\xB0\xE5\xAE\x89\xE6\x97\xB6\xE4\xBB\xA3\xE7\xA7\x91\xE6\x8A\x80\xE8\x82\xA1\xE4\xBB\xBD\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8/CN=mail.gdca.com.cn
   i:/C=CN/O=Global Digital Cybersecurity Authority Co., Ltd./CN=GDCA TrustAUTH R4 EV SSL CA
---
Thank you for your remind. We had fixed it.
Comment 17 by katjoyce@google.com, Jan 11 (5 days ago)
Unfortunately, the log server at https://ctlog.gdca.com.cn/ct/v1 did not meet the 99% uptime requirement specified in Chrome's Certificate Transparency Log Policy, having only 97.589% of availability probes being successful over the initial compliance monitoring phase.

To re-apply for inclusion, please create a new log (or clear this log, give it a new key, and ideally also a new URL) and create a new chromium bug for the new inclusion request.
Comment 18 by hanjie77...@gmail.com, Jan 12 (5 days ago)
Thanks for your reply. 
When we checked the log of the server, we had a question. Since the monitoring tests started, the server got the requests:
get-sth averaging about every two minutes;
get-roots about 4 requests per day;
add-chain/add-pre-chain,get-entries,get-proof-by-hash,get-sth-consistency averaging about every two hours.
But at Dec 17, 2016, we only got a request for add-pre-chain at 1:29am and a request for add-chain at 3.29. Also only two  requests for get-entries,get-proof-by-hash, get-sth-consistency. The request for get-sth averaging about every minute.
And from Dec 18, 2016, the requests restored the same as the original. 
We expect to know whether the tests were changed or the requests were lost.
Sign in to add a comment