That's somewhat working as intended - content_shell isn't setting up CT information, and so we fail closed.

To more specifically expand on this: In the current //net code, for CAs that have "Don't trust unless accompanied by CT information (Symantec)", then it's the embedder's responsibility to make a decision about how CT should work.

For Google code (e.g. //chrome, android webview), we use Chrome's CT log policy, and wire up the set of recognized logs - logs which we require to be updated regularly (to make sure the CT logs are still trusted), and that allows such certificates to work.

For other embedders, they need to make a decision - they can support Chrome's CT policy, in which case, they can setup a MultiLogCTVerifier and call AddLogs to add Chrome's recognized logs, or they can disable CT entirely, by setting up a CTPolicyEnforcer that says everything complies with that applications' CT policy. However, it needs to be an explicit decision - do you want to trust Google's CT actions (which also means regularly updating), or do you want to develop your own policy, or do you want to just disable CT entirely (which also means fully trusting Symantec, and hoping they won't screw up again).

For something like content_shell, answering that question isn't exactly easy. We know content_shell isn't the "most secure" way to browse the web (e.g., lacks safe-browsing integration), and some of the security model differs from say Chrome, so I left the existing behaviour, which is "fail closed in the event of suspect CAs that would otherwise require support from Google infrastructure/policies"

Happy to discuss this decision more, but that's the context for what I meant by "WorkingAsIntended"

Now, it may be that content_shell should fail open (insecure), in which case, it's like I said - a matter of setting up a CTPolicyEnforcer - but since no one centrally manages the security posture of content_shell and its' security policy, I opted for the default I thought was most sane :)

Thanks for your thorough explanation. As you might suspect we've hit this issue in some Opera products too (not just content_shell). We'll have to make a decision how to handle this. Feel free to close this for now, if you have no use for it for content_shell.

I'll close it for now, but like I said - in the absence of other guidance folks, I went with the default that I thought made sense - but it's something that can absolutely be discussed.

It also may be that our default later turns out to be "fail open" - that is, that it's better to have a 'less secure' browser than one that doesn't work. There are pros and cons to that, including threat models, but it's a discussion that can be had.

Adding some //content/shell OWNERS in case they wanted to revisit & reopen.

Hi

I am experiencing the same issue that's I can't open Amazon.com
It show the message "CERTIFICATE_TRANSPARENCY_REQUIRED"
I check google CT log server and I can see amazon.com's certificate is fully 
logged, that is redaction is not used.
https://www.google.com/transparencyreport/https/ct/ 
However the website can be opened by Chrome 54

So may I think below result is true?

(1)In some versions of Chrome 53 browser logic checks certificate transparency for intermediate and root certificates, it it doesn't exist the browser won't open that website

(2)In latest version Chrome 54 browser won't check certificate transparency for intermediate and root certificates


my testbed:
Chrome 53.0.2785.89
Windows 7

Thanks

This is not the same issue. You sound like you're having an issue with Chrome 53, while this is about Chromium's content_shell target.

Can you please file a *separate* bug and attach a net-internals log per these instructions? Thanks!
https://dev.chromium.org/for-testers/providing-network-details

A new bug is useful, but no, it's not that 53 and 54 differ, it is that 53 is too far out of date and is not the current Chrome release.

Ah right, you mentioned that had a very tight expiration... I think we probably ought to change that UI then to call out updating the browser.

Thanks
I have gotten the root cause, it is the  issue 664177