Please collect and attach a chrome://net-export log showing the problem. If you can also attach a log from windows showing it working that might also be useful for comparison.
Instructions can be found here: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Thank you for taking a look at this! I sent you the full logs via mail cause I'm not quite sure if I wanna disclose them publicly with all the settings that are included.

What I already identified as a difference: On Windows in "PROXY_CLIENT_SOCKET_WRAPPER" I get:
-------------
t=593 [st=591]     -SSL_CONNECT
                    --> cipher_suite = 49199
                    --> is_resumed = true
                    --> next_proto = "h2"
                    --> version = "TLS 1.2"
-------------

While on Linux I get
-------------
t=29701 [st=238]     -SSL_CONNECT
                      --> net_error = -214 (ERR_CERTIFICATE_TRANSPARENCY_REQUIRED)
-------------

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

As the issue seems to be out of scope for us to triage it from our end (i.e.,Configuring/adding corporate SSL-proxy...) hence adding "TE-NeedsTriageHelp" and requesting someone from respective team to have a look into it and help in further triaging.

Thanks!

I could reproduce this behaviour by using "mitmproxy" [1] on another machine.

Steps to reproduce:
* Install mitmproxy
* Start mitmproxy. E.g.: mitmproxy -p 8181
* Add mitmproxy's CA (.mitmproxy/mitmproxy-ca.pem) to system store
* Configure Chrome to use localhost:8181 as proxy
* Open any https Site

Result:
NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED is shown


[1] https://mitmproxy.org/

Please provide the full and exact details for how you're doing 

* Add mitmproxy's CA (.mitmproxy/mitmproxy-ca.pem) to system store

It's likely you're doing so in a way that causes it to believe it's a "default trusted" CA (e.g. by patching certain Chrome dependencies), rather than "user/enterprise trusted"

I'm not patching any Chrome dependencies but I do in fact add the
certificate to the system trust store so that Chrome might think it's
"default trusted". This, to my understanding, is the default way of doing
it on Linux. [1]
I'm using Arch Linux and with mitmproxy it looks like this:

-----------------
-> cp ~/.mitmproxy/mitmproxy-ca-cert.pem
/usr/share/ca-certificates/trust-source/anchors/
-> update-ca-trust
-----------------

but it's similar on Ubuntu [2] and others. I see where you are pointing and
I think this behaviour of Chrome might get more people in trouble than just
me. One has to add the (proxy) certificate this way because there are other
tools and components that are also using the system trust store. So just
"not adding" the cert there and instead adding it directly in Chrome might
solve the problem for Chrome but break other use cases.


[1] https://github.com/rcrowley/certified/wiki/Trust-your-CA-on-Linux
[2]
http://manpages.ubuntu.com/manpages/trusty/man8/update-ca-certificates.8.html

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I am also experiencing this error on Chrome 68.0.3440.84 on macOS 10.13.6. I was going to file a new report but it seems related as I am also behind a corporate SSL-proxy, but not on Linux. Should I file a report for Mac?

Yes, please file a separate report for Mac, including the site or certificate chain you're encountering this with.

Thanks for providing further details about how you're adding. I'm going to look into how Arch Linux is managing its CA trust - it's possible it is (incorrectly) modifying the trust store (e.g. using p11-kit to potentially report as 'default trusted', subjecting it to the CT requirement).

Can you clarify which version of Mozilla NSS you're using? 

If you're on NSS 3.30, it's likely that the patch in https://bugzilla.redhat.com/show_bug.cgi?id=1207335 has "done the wrong thing" by renaming the 'admin + default' slot to "NSS Builtin Objects", thus resulting in us treating it as default trusted on Linux (due to https://cs.chromium.org/chromium/src/net/cert/known_roots_nss.cc?sq=package:chromium&dr=C&g=0&l=53 ).

From a user perspective, this can be worked around by ensuring you're not using p11-kit-trust or correcting p11-kit-trust to not name the slot as such (as Chrome 68+ appropriately distinguishes the trust root status, if you've got NSS 3.30+ installed and the PK11_HasAttributeSet function). We can explore adding a short-circuit for when you're on NSS 3.30+ and the function resolves, but that would not be available until Chrome 70. The user-level workaround (not having p11-kit-trust pretend to be the Mozilla store) seems a viable solution.

I'll go ahead and grab this ( https://chromium-review.googlesource.com/c/chromium/src/+/1167479 ) , although I think p11-kit-trust is wrong for how it designed that to stuff it all into a single slot.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b0784bef916569b6e4f06a6dce95b75a8a2cf10a

commit b0784bef916569b6e4f06a6dce95b75a8a2cf10a
Author: Ryan Sleevi <rsleevi@chromium.org>
Date: Wed Aug 08 19:43:02 2018

Don't exercise legacy path for known roots on modern NSS

NSS 3.30 introduced PK11_HasAttributeSet, which allows callers
to query the PKCS#11 tokens for given PKCS#11 attributes. The
same release also added attributes to the default NSS trust
store indicating they were part of the default store - i.e.
they were not added by admins.

Prior to NSS 3.30, the only way for determining 'default'
trust was to query the token and slot name, as nssckbi.so,
the read-only default trust store. Unfortunately, other
libraries, such as p11-kit-trust, decided to emulate that, but
also included administrative and user-added roots in the store,
resulting in user-added roots being subjected to public trust
requirements.

While the issue is in p11-kit-trust not observing the
semantics that NSS relied on (e.g. by adding themselves as a
separate token/slot, or preserving the 'default-only' nature
of the .so), work around this by adding a short-circuit when
the PK11_HasAttributeSet symbol is resolved.

This short-circuit can be reasoned about as safe, as the other
change in M68 - to use GetNetTrustAnchorHistogramForSPKI -
ensures that publicly trusted roots are recognized as such. This
path only handles the "old Chrome, new trust store" scenario,
which is quite rare.

Bug:  868811 
Change-Id: I21989ee3e0c59dd9bfd199a6b13334637f0772c5
Reviewed-on: https://chromium-review.googlesource.com/1167479
Reviewed-by: Eric Roman <eroman@chromium.org>
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581665}
[modify] https://crrev.com/b0784bef916569b6e4f06a6dce95b75a8a2cf10a/net/cert/known_roots_nss.cc

I'm using "core/nss 3.38-1" (https://www.archlinux.org/packages/core/x86_64/nss/):

-> % /usr/bin/nss-config --version
3.38.0

-> % ldd /usr/lib/libnss3.so                                   
        linux-vdso.so.1 (0x00007fff74ee2000)
        libnssutil3.so => /usr/lib/libnssutil3.so (0x00007fcf5bb03000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fcf5b93f000)
        libplds4.so => /usr/lib/libplds4.so (0x00007fcf5b73b000)
        libplc4.so => /usr/lib/libplc4.so (0x00007fcf5b536000)
        libnspr4.so => /usr/lib/libnspr4.so (0x00007fcf5b2f8000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fcf5b2d7000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x00007fcf5c085000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fcf5b2d0000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007fcf5b2c6000)

which itself depends on "core/p11-kit 0.23.12-1" (https://www.archlinux.org/packages/core/x86_64/p11-kit/):
-> % /usr/bin/p11-kit list-modules
p11-kit-trust: p11-kit-trust.so
    library-description: PKCS#11 Kit Trust Module
    library-manufacturer: PKCS#11 Kit
    library-version: 0.23
    token: System Trust
        manufacturer: PKCS#11 Kit
        model: p11-kit-trust
        serial-number: 1
        hardware-version: 0.23
        flags:
               write-protected
               token-initialized
    token: Default Trust
        manufacturer: PKCS#11 Kit
        model: p11-kit-trust
        serial-number: 1
        hardware-version: 0.23
        flags:
               write-protected
               token-initialized

I ran "/usr/bin/trust dump --filter=pkcs11:object=mitmproxy" and attached the output as mitmproxy_trust.txt. Let me know if you need anything further.

Thanks. p11-kit-trust is known to cause issues in Chrome due to improperly impersonating the NSS root store. In this regard, it's "working as intended" (in that p11-kit-trust is wrong), but the Comment #13 above shows the patch that introduced the broken behaviour.

Works like a charm with Chrome 70. Thank you very much!