Adding ARC tag as this is mostly an ARC issue.  Leaving SSL tag in case they have policy advice.

*bump*
Are there any expectations of timescales when this might be looked at ?  It's the first time I've posted here so not sure what to expect.

Some context here - many US schools are taking up Chromebooks and using Google Classroom to delivery educational content.  (One school district I'm in contact with has "thousands of Chromebooks").
Chromebook updates are crippling (saturating) internet connection and so intercepting and caching these is critical to delivering high quality learning experience for many thousands of pupils.

Hope you can see why I want to help! ;)

Steve,

Your more recent update leaves me a bit confused to the issue. I understood this was primarily with respect to Android apps. I missed the subtlety in your original message, and thus want to confirm: You're concerned that the ChromeOS updater presently respects your locally-installed certificates, but to support Android apps, you need to disable the inspection, which also means that the updater no longer goes through your caching appliance?

I ask, because by design, ChromeOS updates should not be respecting MITM certificates, so I'm somewhat surprised to hear that you've come to rely on that feature. I may be misunderstanding, though, so I wanted to make sure I understood both the current flow (without Android apps), the current flow (with Android apps), and the desired flow that this feature request is tracking.

Thanks for your response... I believe I can clarify based on further testing.

The ChromeOS updates are delivered over HTTP and are cachable - which is great.
The "problem" I'm attempting to convey here, is that once our device's SSL certificate has been installed to the Chromebook, we can succesfully intercept all https traffic - typically generated from the Chrome Browser by browsing https websites.

However, even with the above in place, as soon as Android Apps are loaded, they flatly refuse to connect to the network due to the certificate error - even though Chrome browsing is still working fine on https.

The only way to allow the Android applications access to the internet, is to disable https interception on our caching proxy server.
Suggested fix is to allow Android apps on ChromeOS to reference the ChromeOS trusted certificate store, such that the same certificate trust relationship can be established between the Andoid apps and the proxy as that which already exists between ChromeOS and the proxy.

I also raised this issue with Google directly, who redirected me to Acer (our Chromebook manufacturer).  Acer's support escalated it to their contact at Google, who has told me to raise it directly with Google lol.

Hoping you can assist with getting this looked at by the appropriate people / team :)

*bump again*
I hope the latest explanation of the issue clarifies the matter I'm trying to get looked at.

Put simply, it looks like ARC (sandbox for running android apps on chromebooks ?) has its own trusted CA certificate store.

I'm suggesting having a shared certificate store with the host OS (ChromeOS in this case), or have a method of installing certificates into the ARC trusted CA certificate store.

Correct. ARC contains the Android trust store, ChromeOS contains the ChromeOS trust store. Marking this as Untriaged to better reflect that we are aware that the trust does not flow either way, and they are intentionally separate at this time.

Note that, regardless, Android Applications would still have difficulty connecting to the network. This is because Android N+ applications do not observe administrative additions to the Android trust store unless they explicitly indicate they are willing to ( https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html ). As such, solutions based on SSL interception will continue to result in a sub-par experience for users.

Assigning to Edman, who is working on eventually bridging the gap between the Android and Chrome OS trust stores.