Thanks for filing the issue...

@Reporter : It would be really helpful if a sample URL/Test file is provided, so that we can investigate the issue further.

Thanks.!

A test URL was provided (https://134.114.138.115:8443); I am unsure how I would be able to proivde a test file however.

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

I was able to repro with the test URL. Certificate verification fails with ERR_CERT_COMMON_NAME_INVALID. Don't know why the captive portal interstitial is triggered, I'm not familiar with that code.

We are experimenting this intermitently with Chrome Version 68.0.3440.84 (Official Build) (64-bit). We have a local intranet asp.net mvc IIS site with self-signed certificate using Windows Authentication. We can not provide a test site since this is a secured env.

The discussion of the false positive portal interstitial began here 5/30 
https://productforums.google.com/forum/#!topic/chrome/F5kD0jrjqtg

There's additional background there and Austin mentions other false portal detection failure cases, as does Jay.  There are some (2012) CrOS portal detection docs mentioned
https://docs.google.com/document/d/1k-gP2sswzYNvryu9NcgN7q5XrsMlUdlUdoW9WRaEmfM

https://sites.google.com/a/chromium.org/dev/chromium-os/chromiumos-design-docs/network-portal-detection

owned by Matt Menke (mmenke@chromium.org (==? mattm@chromium.org,see #6) ).  If mmenke is not mattm, he may be able to point you a Windows resource person.

Why is there no chrome://network-errors/ link that displays captive portal interstitial?


Check with 

Assigning to meacer for further diagnosis from the captive portal detection side, I was able to reproduce on stable at the stated URL.

Re #8: The link you are looking for is at chrome://interstitials

This is probably caused by the known captive portal list. Investigating.

This is caused by this entry: https://cs.chromium.org/chromium/src/chrome/browser/resources/ssl/ssl_error_assistant/ssl_error_assistant.asciipb?rcl=a15479c5e22a80dd50fe90d4e596f20c4e9c2d40&l=33

We were assuming all certificates with this subject public key were captive portals, which apparently is not the case. Apologies for all the inconvenience this caused.

I'm going to push an update to remove this entry from the list. In the meanwhile, you can use the following command line flag as a workaround to disable this feature:

--disable-features=CaptivePortalCertificateList

Please do not remove that certificate entry. Auth.impulse.com is a certificate used for captive portals and is also used to administer said captive portal. Portal.myweblogon.com is also in the same certificate as a SAN DNS name but not listed there; is that covered under the same aspect given it’s the same certificate? 
Just to clarify, I’ll work to get the administration pages’ certificate updated to no longer use that same certificate as the portal to prevent administrators and network engineers from encountering this error. 

The interstitial is triggered based on the fingerprint of the public key of the certificate. The DNS name is not considered -- it's only used as a comment in that file.

So just serving that certificate will trigger a captive portal warning, regardless of the domain name it's served from.

Side question; how would that certificate get updated to the renewed certificate upon previous certificate expiration? Or given the hash, it may not even matter?

Yes, if the new certificate has the same SPKI, it would still match. There are indeed multiple certificates for auth.impulse.com with the same SPKI information:

https://crt.sh/?q=d92d97e4d17ce28a7c844f58b0d1cda44e604b959cff998435e01777777ce715 (expired)
https://crt.sh/?q=269b0459bd0bc11b1cc6ccb76a983929ecf4f3b7b20e401b179ca344a600dca2 (current)

Okay that makes sense. So for clarification, the only time that page should occur is:
Upon an ssl error, chrome will check if the SSL mismatch is one of the provided certificates (e.g. auth.impulse.com). If so, it will display a captive portal page. Are there any other major use cases or edge condition that would result in this page being shown so I have a better understanding of this workflow? For example, does the port matter in showing the page or does the URL being localhost, a private IP, public IP, etc matter? Thanks for your prompt responses and assistance in this. 

The URL is not taken into account, so localhost, private/public IP doesn't matter. However, the only SSL error must be a name mismatch for this feature to trigger.

For reference, this is the code that checks the list: https://cs.chromium.org/chromium/src/chrome/browser/ssl/ssl_error_assistant.cc?rcl=b85f3ffc2ddbd70a838418fa202d2e1b33420221&l=203

There are two other cases where we display this interstitial:
- The OS reports that it's detected a captive portal
- Chrome itself found that it's detected a captive portal

Here is a brief write up explaining these features: https://docs.google.com/document/d/1FIl2hrnkuV7dZ-xrpa4M-HMFa5FimI9aKKkLi_bLJaI/edit?usp=sharing

Thank you again for the additional explanation. One last thing I still do not fully understand yet is when I navigate to testserver (testserver > 10.102.10.70 in /etc/hosts is a test server operating with the auth.impulse.com certificate on port 8443) I get the captive portal prompt page correctly. But when I navigate directly to the IP on the same server on the same port, I get a different response, as shown below:
https://i.gyazo.com/23adeb1b9b60325bde697593ac48802e.png
https://i.gyazo.com/ac170decbbc528f9d570aeb8c9ef4d3a.png


With the understanding I have based off the URL not being taken into account, why does navigating via IP change this behavior?

Can you please attach net logs for the IP and non-IP cases? Instructions are here: https://www.chromium.org/for-testers/providing-network-details (You might want to try this in a clean profile to prevent any private data getting logged)

meacer@ Thanks for the chrome://interstitials ref.  I posted  bug 875623  to have it added to the chrome://chrome-urls list.

Apologies for the delay, I have attached the net log for the IP and localhost version that both produce an auth impulse certificate:

Deleted: chrome-net-export-log-localhost.json 82.2 KB

chrome-net-export-log-localhost.json 82.2 KB View Download

Deleted: chrome-net-export-log-IPAddress.json 405 KB

chrome-net-export-log-IPAddress.json 405 KB View Download

Any movement on this issue?
I'm facing similar issue around connecting to a self signed site with its IP address, and getting redirected to the 'connect to network' page, with an option to 'Connect' which takes me to http://www.gstatic.com/generate_204
Happy to help out if I can add any context here. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2b3cf454c1d96333719df413d73a50e651c99fec

commit 2b3cf454c1d96333719df413d73a50e651c99fec
Author: Mustafa Emre Acer <meacer@chromium.org>
Date: Fri Sep 21 05:33:13 2018

Remove the SPKI fingerprint for auth.impulse.com from captive portals list

Bug:  870038 
Change-Id: I856efd083382cb27f01ea37abbfcbb04941ec0c4
Reviewed-on: https://chromium-review.googlesource.com/1176582
Commit-Queue: Adrienne Porter Felt <felt@chromium.org>
Reviewed-by: Adrienne Porter Felt <felt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593084}
[modify] https://crrev.com/2b3cf454c1d96333719df413d73a50e651c99fec/chrome/browser/resources/ssl/ssl_error_assistant/ssl_error_assistant.asciipb

@Meacer

auth.impulse.com is a captive portal certificate and should not be removed from that list as I mentioned above. This bug is not a bug, just a lot of confusion.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f29466ff54b071c76911c980f6b9204eff8f0e89

commit f29466ff54b071c76911c980f6b9204eff8f0e89
Author: Adrienne Porter Felt <felt@chromium.org>
Date: Fri Sep 21 13:46:41 2018

Revert "Remove the SPKI fingerprint for auth.impulse.com from captive portals list"

This reverts commit 2b3cf454c1d96333719df413d73a50e651c99fec.

Reason for revert: <INSERT REASONING HERE>

Original change's description:
> Remove the SPKI fingerprint for auth.impulse.com from captive portals list
> 
> Bug:  870038 
> Change-Id: I856efd083382cb27f01ea37abbfcbb04941ec0c4
> Reviewed-on: https://chromium-review.googlesource.com/1176582
> Commit-Queue: Adrienne Porter Felt <felt@chromium.org>
> Reviewed-by: Adrienne Porter Felt <felt@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#593084}

TBR=felt@chromium.org,meacer@chromium.org

Change-Id: I0c158c192ebd88c3cd586da3fca7cd6963f594f4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  870038 
Reviewed-on: https://chromium-review.googlesource.com/1238375
Reviewed-by: Adrienne Porter Felt <felt@chromium.org>
Commit-Queue: Adrienne Porter Felt <felt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593167}
[modify] https://crrev.com/f29466ff54b071c76911c980f6b9204eff8f0e89/chrome/browser/resources/ssl/ssl_error_assistant/ssl_error_assistant.asciipb

Thank you for reverting the aforementioned commit. Should I create a separate issue for the experience of comment 19 through comment 22 since the core of this issue was not a bug, but just a misconception?