Please help to cc eranm@chromium.org and google-ct-logs@googlegroups.com 

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 ?

 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.

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.

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.

This log server's certificate has expired (https://crt.sh/?id=48314025).

GDCA, do you plan to renew it?