+ rsleevi: can you comment if this is feasible?

I can confidently say this is a very intentional WontFix, on security and standards grounds. This can be effectively mitigated a number of ways - including simply configuring the server to serve the correct AIA. This has zero usage on the Public Web, but would have significant security risk (LDAP as a protocol is a bit of a tire fire, especially with its use of BER), and because it would work before a verified chain is obtained, would end up being exposed to the Public Web - we could not segment it out for Enterprise.

1) Serve the correct chain on the server
2) Configure HTTP AIA endpoints (the most common case of such LDAP URIs is Active Directory, which ADCS will also configure IIS with an HTTP AIA by default)

We're not going to ship or write an LDAP library to run and be exposed to the Web at large, that'd be... a road to sadness :)

(They'd also be getting these errors on Android, iOS, and macOS, so...)

davidben pointed out that I misread - ERR_CERT_INVALID != ERR_CERT_AUTHORITY_INVALID

Can you confirm (with netlog) the error being returned?

marchuk: please provide an answer to Ryan's question above

Thank you for opening this bug on behalf of the case that I opened with Google for Work Support under case 15749240.

Rsleevi: You mentioned that we would be getting these errors on Android, iOS, and macOS which is incorrect. This site is accessed internally by about 4500 employees and over around half of them are currently running macOS without any certificate issue being raised by the Chrome Browser.

I am not a member of our internal PKI group, I am just an earlier tester of the Chromebook in our environment. That being said, would it be possible to join a brief conference call sometime next week to discuss this with a member of our PKI team? 

We are committed to adopting Google's ecosystem into our enterprise (G-Suite, GCP, Chrome/Pixelbooks, etc...) but need to see if this can be ironed out in any other way outside of potentially impacting all the other internally issued certificates within our domain.

If anyone needs additional information from me, please don't hesitate to reach out.

Thanks for the report.

The issue is with the leaf certificate's Key Usage
(Not the presence of an ldap:// AIA URL, which FWIW is quite common)

NSS (crypto library being used for cert verification on ChromeOS) requires that the leaf certificate (TLS Server Auth) contains either keyEncipherment or keyAgreement.

However in this case it contains only digitalSignature.

My suggestion is to add keyEncipherment when generating the certificate, as is typically done.