Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 3 users
Status: WontFix
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
Certificate Transparency - GDCA CT Log Server Inclusion
Reported by hanjie77...@gmail.com, Oct 10 2016 Back to list
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 
Comment 4 by eranm@chromium.org, Oct 10 2016
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
Comment 5 by eranm@chromium.org, Oct 10 2016
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.
Comment 7 by eranm@chromium.org, Oct 10 2016
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 ?
Comment 9 by eranm@chromium.org, Oct 10 2016
Owner: katjoyce@google.com
Comment 10 by eranm@chromium.org, Oct 10 2016
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!
Comment 15 by robst...@gmail.com, Oct 24 2016
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.
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.
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.
I can confirm that there have been no changes made to our method of compliance testing, and your full compliance monitoring phase was tested using the same system we use to test every log.

Our compliance monitoring tool contains sections that are responsive to the feedback it receives from the log it is testing.  The behavior you saw on December 17th was due to the second reason that this log has, unfortunately, not met the requirements of the Chrome Certificate Transparency Log Policy: on December 17th, the log did not include a certificate into its tree within the required 24 hour maximum merge delay window.

The details of this blown MMD can be found by looking at log entry 802:

The STH received just before the testing certificate was submitted was:

STH:
{
  "tree_size": 802
  "timestamp": 1481945343528 (2016-12-17 03:29:03 +0000)
  "sha256_root_hash": "y36F174s4fUmfcdFMFF9MKZFTeV3fWzNoLqf3KYZUxo="
  "tree_head_signature": "BAMASDBGAiEA6znud3gY5Vd/KlZ6+8ts62Q6Gs0U0UYI3LC9WSBUsYMCIQDYkCaxnDVbowraTBYgnOLyQIW7rOTjwaTcAiSilmlvbQ=="
}

Note that the tree size is 802 (and that log entries are 0 indexed, so a tree of size 802 contains log entries 0-801).

The SCT returned for our certificate was:

SCT:
{
  "sct_version":0,
  "id":"kkow+Qkzb/Q11pk6EKx1osZBco5/wtZZrmGI/61AzgE=",
  "timestamp":1481945345477, (2016-12-17 03:29:05 +0000)
  "extensions":"",
  "signature":"BAMASDBGAiEAzN6L1rQHRGEHYPcVfv3ZywhSIBmii4hp41scfy+tk3gCIQDOhy1VyjxVDh5oZlUQrtFacNXvGAanfgVFw80OCEroyg=="
}

You can see that the timestamp on the SCT is (2016-12-17 03:29:05 +0000)

Here is an STH returned by the log more than 24 hours later:

STH:
{
  "tree_size": 802
  "timestamp": 1482032763528 (2016-12-18 03:46:03 +0000)
  "sha256_root_hash": "y36F174s4fUmfcdFMFF9MKZFTeV3fWzNoLqf3KYZUxo="
  "tree_head_signature": "BAMASDBGAiEA/XfYR876WLhYxWkqSrK/64n5n9fXe6RLE0nuMvdLPF4CIQCZgOUL1IWyRK9FuYkPcFJLtPeZCsXw4osUAkuWYdxyUg=="
}

You can see that the tree size is still 802, and so the certificate was not included within the 24 hour MMD.

Unfortunately, the team was not able to check and validate this event until we came back in January, after the holiday period, hence the delay in reporting this incident.

As previously mentioned, if you'd like 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.
Status: WontFix
Yes,you are right. The certificate was not included within the 24 hour MMD due to an error of the etcd cluster, and it was solved after the server restarted. 
Thanks for your time. We will re-apply for inclusion with a new log later.
Sign in to add a comment