As per comment #0 Issue is related to Cisco Network and as we are unable to test this form our end. Hence adding TE-NeedsTriageHelp label to this issue requesting Network team to have a look into this it for further triaging.

Thanks.!

Could you provide a net-export log demonstrating the problem? Instructions: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

attached

Deleted: chrome-net-export-log.json 1.1 MB

chrome-net-export-log.json 1.1 MB View Download

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

The ERR_CERT_AUTHORITY_INVALID suggest that captive portal is presenting invalid certificate.

t=92697 [st=  0] +SOCKET_POOL_CONNECT_JOB  [dt=122]
                  --> group_name = "ssl/www.google.co.il:443"
t=92697 [st=  0]   +SOCKET_POOL_CONNECT_JOB_CONNECT  [dt=122]
t=92697 [st=  0]      TCP_CLIENT_SOCKET_POOL_REQUESTED_SOCKET
                      --> host_and_port = "www.google.co.il:443"
t=92697 [st=  0]     +SOCKET_POOL  [dt=9]
t=92705 [st=  8]        SOCKET_POOL_BOUND_TO_CONNECT_JOB
                        --> source_dependency = 43991 (TRANSPORT_CONNECT_JOB)
t=92705 [st=  8]        SOCKET_POOL_BOUND_TO_SOCKET
                        --> source_dependency = 43992 (SOCKET)
t=92706 [st=  9]     -SOCKET_POOL
t=92819 [st=122]      CONNECT_JOB_SET_SOCKET
                      --> source_dependency = 43992 (SOCKET)
t=92819 [st=122]   -SOCKET_POOL_CONNECT_JOB_CONNECT
                    --> net_error = -202 (ERR_CERT_AUTHORITY_INVALID)
t=92819 [st=122] -SOCKET_POOL_CONNECT_JOB

For that netlog could you describe precisely what you did, what you expected to happen, and what actually happened? 

As noted in comment #7, just looking at the log I see various connections failing due to invalid certificates, which is what I would expect to happen if you tried to connect to an HTTPS website when behind a captive portal.

hi my name is Surafel we have been doing various tastes and we have found that only google.com is the only browser that does not let users enter the portal 
we even tried on chrome with a different browser and it works ,so we have come to a conclusion that the problem narrows down to google.com
we need you'r help on this issue ,because it is impossible to change a browser on thousands of users computer specially when they are guest users.

best regards
 

BTW , This issue didnt exist before 1 month .
Some last  update of chrome did it.

בתאריך יום ג׳, 26 ביוני 2018, 10:18, מאת surafel… via monorail ‏<
monorail+v2.3704625973@chromium.org>:

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

another details from Cisco  : 
Background Information

Web authentication is a Layer 3 security feature. It blocks all the IP/data traffic, except DHCP-related packets/ DNS-related packets, from a particular client until a wireless client has supplied a valid username and password.Web authentication is typically used by customers who want to deploy a guest-access network.Web authentication starts when the controller intercepts the first TCP HTTP (port 80) GET packet from the client.

In order for the client's web browser to get this far, the client must first obtain an IP address, and do a translation of the URL to IP address (DNS resolution) for the web browser. This lets the web browser know which IP address to send the HTTP GET. When the client sends the first HTTP GET to TCP port 80, the controller redirects the client to https:<virtual IP>/login.html for processing. This process eventually brings up the login web page.

Prior to releases earlier than CUWN 8.0 ( i.e up to 7.6), if  the wireless client presents an HTTPS page (TCP 443), the page is not redirected to the web-authentication portal. As more and more websites begin to use HTTPS, this feature is included in releases CUWN 8.0 and later. With this feature in place, if a wireless client tries https://<website>, it is redirected to the web-auth login page. Also this feature is very useful for the devices that send https requests with an application (but not with a browser).



Certificate Error

The warning message "certificate is not issued by a trusted certificate authority." appears on the browser after you configure the https-redirect feature. This is seen even if you have a valid root or chained certificate on the controller as shown in Figure 1 and Figure 2. The reason is that the certficiate you installed on the controller is issued to your virtual IP address. 

Note: If you try an HTTP-redirect and have this certifcate on the WLC, you do not get this certificate warning error.  However in the case of HTTPS-redirect, this error appears.

When the client tries HTTPS://<web-site> , the browser expects the certificate issued to the IP address of the site resolved by the DNS. However, what they receive is the certificate that was issued to the internal web server of the WLC (virtual IP address) which causes the browser to issue the warning. This is purely because of the way HTTPS works and always happens if you try to intercept the HTTPS session in order for web-auth redirection to work.

Hi, it still sounds to me like this is working as expected. As the details from Cisco said, if you try to load an HTTPS website, you will get a certificate error.

The one thing that may be of note is that google.com is on the HSTS list, so it will always load over HTTPS even if you didn't type https:// at the start.

So not being able to load google.com is a bit of a red-herring I think. It should work if you just load a http:// page that is not HSTS enabled.

Going back to the original comment, you mentioned whitelisting various hosts to bypass the connectivity check. This sounds counter productive, the captive portal detection code is intended specifically to help logging into the captive portal and avoiding these https errors. So I think the first step would be to remove those whitelists and then try to debug the error you were originally seeing.

Correction: google.com is not using HSTS (but some subdomains are, like mail.google.com). So in that case, just loading the http:// scheme rather than https:// should get redirected to the captive portal without an error.

@Comment 14: Google does serve the header, just not preloading (a quick test at hardenize.com shows it setting with a 1 day policy)

So I think, as you note in Comment #13, that google.com not loading is WAI. Testing in other browsers, they may not have (previously) noted the HSTS policy.

Further, as you note, whitelisting the captive portal checks is extremely counter-productive - if they were allowed, clients would make HTTP requests specifically to those portal pages to allow the redirect to continue.

@reporter: If you remove those whitelists, does the problem go away?

[asafkostika]:  Could you please respond to comment #15?

Closing due to lack of response.