Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 3 users
Status: Verified
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: Linux, Android, Windows, Chrome, Mac
Pri: 3
Type: Feature

Sign in to add a comment
Certificate Transparency - PuChuangSida CT Log server inclusion.
Reported by, Nov 22 2016 Back to list
Steps to reproduce the problem:
Log Server URL:
MMD: 24 hours
HTTPS supported: yes 
Operator: Beijing PuChuangSiDa Technology Ltd.
- email:
- Phone: +86 17316230527
- contact persons: PCSD IT Operation

Log Server Public Key:
-----END PUBLIC KEY-----

A description of the Log:
The Compliance Monitoring Root is added to the CT Log. 

Accepted Roots: 

What is the expected behavior? 

What went wrong?
PuChuangSiDa CT Log server apply for inclusion in Chrome.

Did this work before? 
2.0 KB Download
Comment 1 by, Nov 22 2016
Components: Internals>Network>SSL
Components: -Internals>Network>SSL Internals>Network>CertTrans
Labels: -Type-Bug Type-Feature
Status: Started
Thank you for requesting monitoring. We have reviewed your request and we
will need more information before we can begin monitoring.

Could you please provide the root certificates you intend to trust?
The certificate chain for is incomplete, containing only the end-entity certificate.  Could you configure your server to serve a complete chain?
Comment 5 by, Nov 23 2016
Thanks for your prompt response. 

During the testing and inclusion period, we are only including Google's monitoring root. After that, we plan to accept all publicly trusted root. We will develop our internal policies to evaluating every root inclusion request. Such policies may include requirement for algorithms, minimum keysize,and similar checks. We may also evaluate the network balance load and scale before we accept a Root certificate.

The certificate of is configured with a complete chain.
I'm going to encourage some discussion as to whether the policy should allow a log to go through compliance monitoring with no roots (bar the Google monitoring root), as there has been criticism of this in the past. If you'd like to contribute your reasons for why you think this should be allowed, the forum thread is:!topic/ct-policy/K_QawRkK0Gw
Thanks for bringing this up, Rob.

Yes, as mentioned in the past, this is not something we want to encourage. I explained more on the list, but this is similar in response to requests for logs from Google and Akamai - that we'd hope to see a clearer policy and inclusion to make sure this is useful and valuable to Chromium users and the ecosystem.
Status: ExternalDependency
Comment 9 by, Dec 15 2016
I attached the revised sets of roots accepted by PuChuangSida CT Log, PCSD_ct_trust_root_certs.pem , please check the attachment.

7.0 KB Download
Thanks. Can you clarify further a bit on your policies about accepting all publicly trusted roots, but still developing internal policies? Do you have a timeline or plan for accepting additional roots?

I ask mostly because you indeed recognized a potential concern (the network balance load and scale before accepting a root), but also indicated plans to accept all publicly trusted roots, and was hoping for more clarity on those policies, so that they can be weighed against the broader Chromium interest.

However, I don't want that decision to block compliance monitoring, so I think it's useful to begin, but I hope we'll see a bit more detail/plan before making the decision to include (assuming it passes the compliance monitoring phase), since the point of the compliance monitoring is partly to ensure the log can/does meet its uptime/load goals for the roots it trusts.
Comment 11 Deleted
Comment 12 by, Dec 19 2016
Thanks. Although we don't have very detailed policy now, we may share some plans and policies as follows,

1, We plan to accept additional root at second half of 2017, it is still TBD as our CT log server need pass Google's compliance monitoring and be included in Chrome successfully. 

2, The root certificate in our log server should be included at least one major browsers or operate system.(IE, Chrome, Firefox,Safari or Windows, MacOS and iOS, Android ).
3, The signature algorithm of root certificate must be ECC or RSA (key size is 2048bit at least).

4, The request CA need provide a estimate number of certificate they submit into our log server so that we can extend our network scales in AWS before we accept the root. 
5,  We will update in Chromium once(or before) we add a new root into our log server. 

6, PuChuangSiDa reserve the right to reject a root inclusion request for any reason. We also may remove the existing root in our log server in case the CA cease operation or it's not publicly trusted any more due to key compromise and similar incident.

Status: Started
Would you like to name your log, or shall I simply dub it "PuChuangSiDa 1"?
Comment 14 by, Dec 20 2016
 Thanks. Please use name: PuChuangSiDa CT Log 1.

NextAction: 2017-03-20
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 20th March 2017 and we will update this bug shortly after that date to confirm.
NextAction: ----
This log has passed the initial 90 day compliance period and we will start the process to add this to Chrome.
Project Member Comment 17 by, Mar 22 2017
The following revision refers to this bug:

commit 588960fc36ee4335083ae671f7109b5b5f1d4d08
Author: robpercival <>
Date: Wed Mar 22 15:47:28 2017

Add PuChuangSiDa CT log to known logs list

They have completed their initial compliance monitoring.

BUG= 667663 

Cr-Commit-Position: refs/heads/master@{#458762}


Rob: Are you going to do the Merge & Merge-Request to M58?
Labels: Merge-Request-58
I'll do the merge request, but eranm@ will handle the actual merge as I do not have commit rights.
Labels: M-59 OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Wiki updated to reflect 59. When this lands to 58, let's update the Milestone and Wiki to reflect this.
Project Member Comment 21 by, Mar 22 2017
Labels: -Merge-Request-58 Hotlist-Merge-Approved Merge-Approved-58
Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit - Your friendly Sheriffbot
Project Member Comment 23 by, Mar 27 2017
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit - Your friendly Sheriffbot
Your change is approved for M58. Please ensure that fix works in canary. If all looks good, merge ASAP so that it will be picked up for next Beta Release, RC cut on (Tuesday-03/28) at 4.00 PM PST.
Project Member Comment 25 by, Mar 27 2017
Labels: -merge-approved-58 merge-merged-3029
The following revision refers to this bug:

commit 98fdca7ac875f8e55a80f8971094411d566cf8eb
Author: Eran Messeri <>
Date: Mon Mar 27 21:14:24 2017

Add PuChuangSiDa CT log to known logs list

They have completed their initial compliance monitoring.

BUG= 667663 

Cr-Commit-Position: refs/heads/master@{#458762}
(cherry picked from commit 588960fc36ee4335083ae671f7109b5b5f1d4d08)

Review-Url: .
Cr-Commit-Position: refs/branch-heads/3029@{#442}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}


Labels: -M-59 M-58
Status: Verified
I've updated and the milestone, and will now close this issue out.

Please use this issue to report any changes in the set of information collected during this process, consistent with
Comment 27 Deleted
I just reported the following to


I have been unable to contact the PuChuangSida CT Log since 2017-05-12
02:45 UTC. The connection to port 443 on times out.

Other monitors have also been unable to contact your log over the last
14 hours:

When do you expect this problem to be resolved?


The server is down due to network issue of AWS. And we also failed to
connect to ec2 server in China.

We are contacting support team of AWS to solve this issue.
We will update the status as soon as we fix it.



2017-05-13 1:05 GMT+08:00 agwa-b… via monorail <>:
This log has fallen well below the availability requirements required by the Chromium CT log policy. The last STH Google's compliance monitoring system was able to obtain was the following, with a timestamp of 2017-05-11 02:50:17 UTC:

The latest timestamp I saw was from 2017-05-12 02:40:17.880 UTC, which seems to match the other monitors. I'm not sure you talk about almost a day earlier, it worked fine that day. It stopped replying since the 12th.
Thanks for pointing that out, the system I took that STH from didn't have the latest STHs; I suspect because the log was not up to provide consistency proofs when it got around to verifying them. I've checked our record of unverified STHs and can see an STH from 2017-05-12 02:30:17.880 UTC:


Nonetheless, the log is well below the availability requirements.
FYI, the bug that tracked removing this log was .
Sign in to add a comment