Issue metadata
Sign in to add a comment
|
Policy configured EAP-TLS network does not prompt user to obtain certificate. |
||||||||||||||||||||||
Issue descriptionChrome Version: <From about:version: Google Chrome 63.0.3239.85> Chrome OS Version: <From about:version: Platform 10032.68.0> Chrome OS Platform: <Samus> Network info: WiFi/ EAP-TLS)> Please specify Cr-* of the system to which this bug/feature applies (add the label below). Steps To Reproduce: (1) Configure EAP-TLS network via Cpanel. (2) On Chrome:settings page, click to connect to the network Expected Result: It should redirect user to get new certificate, if no certificates are present. Actual Result: OS tries to connect without redirecting to the enrollment URI. Note: Enrollment URI is present in chrome://policy. How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?) Always What is the impact to the user, and is there a workaround? If so, what is it? Please provide any additional information below. Attach a screen shot or log if possible. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Dec 11 2017
I wasn't able to reproduce on 63.0.3239.85 (10032.68.0-17.12.06) either. Could it be that a certificate was present on the device, but rejected by the server? From reading hte logs, I can see a 'certificate-required' event in var/log/ui/ui.20171207-195026:[1561:1561:1207/115528.706898:ERROR:device_event_log_impl.cc(156)] [11:55:28.706] Network: network_connection_handler.cc:98 Connect Failure: certificate-required: /service/9 this is supposed to have triggered the "certificate required" dialog which would forward to the enrollment URI. Has it not? I see a few passphrase-required/connect-failed events too, which should be unrelated and probably come from other tests.
,
Dec 11 2017
Note: Also tried on 65.0.3287.0, Chrome OS also prompted me to go to the URL there.
,
Dec 11 2017
Also, could you please tell us which session type this was in (e.g. regular session/guest/public session/sign-in screen). We currently have a list of session types[1] where we don't do cert enrollment on missing certificate, maybe this is the issue? [1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/enrollment_dialog_view.cc?l=264
,
Dec 11 2017
this is supposed to have triggered the "certificate required" dialog which would forward to the enrollment URI. Has it not? Nope. One thing, I noticed is, this happens only the first time the user logs in. Below are the steps I followed 1) Connect to the network successfully after adding the certificate (by manually navigating to the cert url). 2) Forget the network and remove the certificate. 3) Click on the network again to connect. This time, I see a "certificate required" dialog. Also, could you please tell us which session type this was in (e.g. regular session/guest/public session/sign-in screen) Regular session. Logged in as a user. The network is fetched by a policy.
,
Dec 12 2017
Sorry, but one more question :-) So when you take a fresh device, enroll it, sign in, try to connect to the wifi, what exactly happens? Nothing? Or does it give you an error message? Could you please give us the chrome://policy contents when this happens? Thank you!
,
Dec 14 2017
Maksim raised another important question: When you say in Comment #5 Step 2) that you Forget the network, does this mean that the network is not managed at this point in time? IIRC it's not possible to "Forget" managed networks.
,
Dec 14 2017
I was not able to repro this issue on Samus ( M63-10032.71.0). @jingwee/Enterprise test team: Can you see if you can reproduce this issue at your end or else please close this as won't fix. When you say in Comment #5 Step 2) that you Forget the network, does this mean that the network is not managed at this point in time? IIRC it's not possible to "Forget" managed networks. > My mistake, that is incorrect. Only removing the client certificate from the certificate manager.
,
Jan 2 2018
Closing this as won't fix #8. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by pmarko@chromium.org
, Dec 11 2017