Depending on the captive portal, this may be working as intended. This is because google.com sets the HSTS header, which explicitly states all certificate errors should be fatal. If your captive portal induces SSL errors, then it would be expected to prevent access to google.com (and transitively, the sign-on)

"Invalid cert" here is ambiguous in this case, as to the error caused. A Chrome NetLog ( https://dev.chromium.org/for-testers/providing-network-details ) would help confirm.

You could also try a site like http://neverssl.com to see if you get redirected to the captive portal.

That’s not the issue—the redirect from the the original destination to the portal works fine. Here’s the issue:

1. User requests http://somesite.com
2. Chrome requests http://somesite.com
3. Captive portal returns redirect to https://wifilogin.example.com
4. Chrome requests https://wifilogin.example.com

All working as intended so far. 

5. wifilogin.example.com presents an invalid cert (didn’t think to check how, but it’s skippable in Safari and Edge)
6. Chrome displays the “log into you wifi” message
7. User clicks the button in the message
8. Go to step 4

I couldn’t find a way to escape this cycle other than by logging in to the captive portal in Edge.

Thank you for providing more feedback. Adding requester "rsleevi@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Right, in that case, a Chrome Net-Log will help confirm the details in 5, including the nature of the error and whether there may be the possibility to workaround.

Presently, the set of errors treated as fatal are those that present security risk in overlooking or present significant enough UI or experience risk in attempting to mitigate/parse (which may then, in turn, present security risk).

Unfortunately I no longer have access to the network in question. If there are logs that stick around for a few days (and are always on) I can ask a friend to see if they can find them. If not, a good start for a reproduction attempt would be to set up a wifi router to redirect all requests to self-signed.badssl.com (not redirecting badssl itself, of course). 

Thank you for providing more feedback. Adding requester "rsleevi@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Setting Needs-Feedback to try to get more information.

Unfortunately, the logs don't stick around. From local testing, self-signed.badssl.com does not trigger the issue. That's why I mentioned in Comment #2 that 'invalid' is ambiguous (or perhaps overloaded)

I suspect that you're encountering ERR_CERT_INVALID, as otherwise, unless it was HSTS, you should have been able to bypass. That said, adding Interstitials label in case ERR_CERT_AUTHORITY_INVALID for a captive portal would trigger an error loop.

I suspect that when the captive portal itself has a bad certificate, this triggers the captive portal detection, which detects (correctly) the connection is behind a captive portal, and shows the captive portal interstitial (chrome://interstitials/captiveportal) instead of the standard SSL one. That interstitial does not have a bypass button, just a "Connect" that leads to the captive portal (which would start the loop again). 

Adding meacer for thoughts on this, I'm thinking if this is the case, then maybe detecting if the captive portal login link == URL that triggered the captive portal interstitial, then show a standard SSL interstitial at that point.

That sounds consistent with the what I saw. Thank you for explaining it better than I could. 

Thank you for providing more feedback. Adding requester "rsleevi@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Chrome uses both its own captive portal detection and the OS reported captive portal status to display the "connect to wi-fi" screen.

Chrome's own detection ignores captive portals and displays a plain SSL error if the portal serves a bad cert. However, Windows and Android is lax with these portals: They report a behind-captive-portal status even if the portal serves a bad cert.

If you started seeing this recently, this might be why you are ending up on the "connect to wi-fi" screen, as the OS integration has only fully launched in Chrome 63.

Hi!

I'm a Google Top Contributor in the Spanish Chrome Forum and a user came to the Forum 4 days ago to tell us about the same problem that g...@canishe.com reported in this issue.

The Forum thread is this one: https://productforums.google.com/d/msg/chrome-es/rn70FZ_Qov4/-DctsE1sAwAJ

He's using Windows 10 and he tells us that he was able to view the portal captive in Edge (I guess because he was able to ignore the certificate error message there).

rsleevi@: if you still need it, I can ask that user to provide us with a Chrome Netlog. Would you want that?

Could someone from Internals>Network>Certificate please have a look at comment#13 and help in triaging this further.

I think Comment #9 covers comment #13.

This is out of scope of triaging from TE end as this requires a wifi setup. Hence adding TE-NeedsTriageHelp for further inputs from dev team.

Thanks!

meacer - can you decide what to do with this bug?

Our Company is facing the same problem. 
(We have enterprise grade Wifi Controller and Captive Portal)

Current Work-around is to ask user to use other Browser like Firefox/I.E. to "Login" first.
(Firefox and I.E. have button to proceed to self-sign cert https captive portal)

Please kindly help.
Thank you very much.

We are also facing the same problem, in Android platform.

Please kindly fix it in future version Chrome.
Thank you very much.