New issue
Advanced search Search tips

Issue 716470 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug
Team-Security-UX



Sign in to add a comment

Repeated net::ERR_INSECURE_RESPONSE errors after proceeding past missing_subjectAltName

Reported by psynn...@gmail.com, Apr 28 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Browse to site with HTTPS self signed certificate without subjectaltname (SAN)
2. Presented with "Privacy Error", NET::ERR_CERT_COMMON_NAME_INVALID, specifically: missing_subjectAltName.
3. Click "Proceed to ... (unsafe)"
4. Page loaded ok.
5. After a minute or so, browse to a sub page within the secure site (on the same server)
6. Several times this will result in corrupted/partial page loads with "net::ERR_INSECURE_RESPONSE" in console. 
7. Refresh page.  Often, errors will continue
8. Finally, after refreshing a few times, you will be presented with the "Privacy Error" warning again.  Repeat from step 3.

What is the expected behavior?
After proceeding past the missing_subjectAltName warning, this should be accepted for the duration of the browser being open.  It should not break page loads and re-appear again.

What went wrong?
Repeated ERR_INSECURE_RESPONSEs, broken page loads due to user being required to re-view and proceed past the Privacy Error page again.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes 57

Does this work in other browsers? Yes

Chrome version: 58.0.3029.81  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 25.0 r0

This is critically broken.  I understand the need for this additional security check (subjectaltname), but after accepting and proceeding past, it should not break page loads a minute or so afterwards and require the privacy error to be shown again.
 
Components: Internals>Network

Comment 2 by rbyers@chromium.org, Apr 28 2017

Cc: sleevi@google.com
Components: -Internals>Network -Blink Internals>Network>SSL
Cc: -sleevi@google.com rsleevi@chromium.org
Components: -Internals>Network>SSL Internals>Network>Certificate UI>Browser>Interstitials
Labels: Needs-Feedback
Interstitials folks: This usually sounds like something related to the SSLManager.

Can you include a log from chrome://net-export (see https://dev.chromium.org/for-testers/providing-network-details )

Comment 4 by psynn...@gmail.com, May 2 2017

I missed a step from the original bug report, which is possibly important:

The self signed certificate had previously been imported into the Windows "Trusted Root Certification Authorities" store via the Internet Options control panel.  The purpose of this was to stop the self-signed certificate warning (and it worked until Chrome 58).

I am trying to reproduce the problem while chrome://net-export is logging - but after 15 minutes or so it has not yet reoccurred.  I shall keep trying during the day.
Project Member

Comment 5 by sheriffbot@chromium.org, May 2 2017

Labels: -Needs-Feedback
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

Comment 6 by psynn...@gmail.com, May 2 2017

Today, after hours of using v58 on the same sites that previously caused issues, I am no longer seeing this problem - possibly due to clearing the cache.

v58 now seems to remember which sites I have seen+proceeded past the NET::ERR_CERT_AUTHORITY_INVALID warning - even for sites I have not imported the self signed certificate (with no SAN).  If this is the intended behaviour then this is great.  During the initial problem report, an interstitial warning would appear every time I would navigate to the site.
Labels: TE-NeedsTriageHelp
Status: WontFix (was: Unconfirmed)
Marking WontFix based on the report in Comment 6 of it being fixed. However, happy to re-open if it turns out this was premature.

Sign in to add a comment