Did this start recently or really already in M-69? I'm asking because M-69 has been out for a while.
I'll take a look at the logs etc. in the next few hours.

So the linked policy has:
(*) a DeviceOpenNetworkConfiguration device-wide policy with
    a certificate {760c58f7-0e68-4a23-94f7-e28068f8e513}
    an auto-connect EAP-PEAP wifi with
      UseSystemCAs: true
      ServerCARef: {760c58f7-0e68-4a23-94f7-e28068f8e513}

(*) a OpenNetworkConfiguration user policy with
    the same certificate as above
    an auto-connect EAP-PEAP wifi with
      UseSystemCAs: false
      no ServerCARef

Weirdly, the shill network config in effect when the feedback was filed (with profile Profile: /profile/chronos/shill
) seems to have EAP.UseSystemCAs: false and an EAP.CACertPEM/0 field, which is a combination not given above.

I'll try to repro this locally.

Could you please ask the customer to show a screenshot of their network configuraiton in admin.google.com? Do they have networks configured "by device" and "by user"?

Also, do they want the "Do not check" setting to be effective in both the device-wide and the per-user network? 

Customer answers: 
>Did this start recently or really already in M-69? I'm asking because M-69 has been out for a while.
They've found this issue in v69.

>Could you please ask the customer to show a screenshot of their network configuraiton in admin.google.com? Do they have networks configured "by device" and "by user"?
Network is configured by device. Screenshots - 
https://drive.google.com/open?id=16kwXdlh1lDlwBG6RJVYPEck0_4uACYDI
https://drive.google.com/open?id=1AC7o-2Qa4EkR_7UL4CDdcOezbaK4qs_9

>Also, do they want the "Do not check" setting to be effective in both the device-wide and the per-user network? 
They want it to be active device-wide.

They also provided video - 
https://drive.google.com/open?id=11xpmdF0YXvxbKpEbt__IV402KNJ9XhAY

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time.
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Thursday, 01/17/19 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

This bug is still going on and I have been awaiting response from Google for repairing this.  Has there ever been resolution to this issue?

Just to confirm, are you still able to reproduce this issue?

NOTE: If you are replying on behalf of an Enterprise Domain, please provide an update from that domain so we can continue to monitor the impact of this issue.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.

Sorry, I was out for a few months. I will take a closer look at this issue.

I think the client behaves correctly as configured according to the policy json in the issue description.
Background:
(*) UseSystemCAs=true is set for the wifi in the policy
(*) A ServerCARef is set for the wifi in policy.

However, the policy json does not match what is shown in the screenshot in Comment #4.
Are you sure that this network is configured in the admin console for the correct Organization Unit?
If yes, I will open a bug with the admin console so they can investigate.

That is incorrect then cause in our console, we have it configured at the top level domain (on a device wide policy) set to "Do not check the server certificate" as shown in the image I attached.

Deleted: Google Admin (HTH-WiFi-NoCert).png 54.8 KB

	Google Admin (HTH-WiFi-NoCert).png 54.8 KB View Download

I have forwarded this to the admin console team and will report back as soon as I have an update.