(Not a security bug, so removing from the sheriff queue. This is the standard HSTS advanced text for our HTTPS interstitials.)

I'm slightly confused why telling the user to retry later is "really bad advice". We would expect that sites will update their certificates, and the site should begin working again in the future.

I'm not sure what the "correct information" is that you expect we tell the user here. If you have constructive ideas for how we might better convey the details of this to users, we can try to see if there are improvements we can make going forward.

Some things I would note:
* We specifically set the net error code to make help center triaging and support easier as well.
* The point of distrusting Symantec certificates is because we cannot be sure that any cert issued by them that we see in the wild is in fact legitimate.
* For a site that sets HSTS and uses Symantec certs, I would argue the suggested user behavior is to close the site and contact the site owner if they are concerned. This seems in line with the current form of the interstitial messages (both the main message and the advanced details).

Thanks for your response.

I think this is bad advice because "Network errors and attacks are usually temporary so this page will probably work later" suggests, first, that this is a network error or an attack, and second, that it may work again in say half an hour, whereas realistically it's only likely to work after several weeks.

I agree that contacting the site owner is a good action to take, but it doesn't appear in the interstitial, it's in the "Learn more" link, https://support.google.com/chrome/answer/6098869#-215

Also contacting the site owner is problematic.  First, it won't get the problem fixed in a useful timeframe and second, in this case at least, this page which users can't reach is Union Bank's only presence on the web, so people would have to think outside the box even to get their contact information.  (The Google SRP works.)  Really the best advice is to use the stable Chrome channel, but I can see why we aren't going to say that.

There's no great solution but I still think that removing the "ADVANCED" link would be an improvement, since it will scare users and (IMO) doesn't provide actionable help.  Removing it will make it more likely that users will click the "Learn more" link.

Adding some folks who may have more opinions on this. I'm not sure how likely we are to make a relatively temporary custom interstitial text for this though (since longer-term we want to treat it just like any other untrusted root).

A Gentle ping...
As per comment #4, requesting asymmetric@,emilyschechter@ to look into this issue and help further.

Thanks..

Clicking the "ADVANCED" button brings up a blurb containing this text: "... its security certificate is not trusted by your computer's operating system ...", which is a false statement, as the Windows OS is just fine with the certificate.
This is witnessed by clicking "Proceed to ...", upon which the Omnibar shows the red "Not secure" warning. Clicking it and going through to the "Certification Path" tab of the certificate dialog, it tells me "This certificate is OK.".

Unable to reproduce the issue on win-10 using chrome reported version latest canary #70.0.3538.5.
Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to a site which uses Symantec certs, e.g., https://www.uboc.com/uboc/home/home.html.  You'll see the "Your connection is not private" page. 
2. Clicked the "ADVANCED" link.
3. Observed that Chrome tells correct information about the issue and the certificate is OK.

reporter@ - Could you please check the issue on latest canary #70.0.3538.5 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 869988.mp4 1.2 MB

	869988.mp4 1.2 MB View Download

I still see the behavior I described.  I don't have the same Chrome version as you, though.  Your screencast shows "70.0.3538.5 (Official Build) (64-bit) (cohort: Stable)".  I see "71.0.3541.0 (Official Build) canary (64-bit) (cohort: Clang-64)".

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

Friendly ping to asymmetric and emilyschechter for thoughts on this one. I agree with cthomp that we probably want to treat Symantec cert errors like any other untrusted root, but would prefer to hear your thoughts before closing this one. 
Also, we now show a special error message after a user gets a few of this types of errors, but I don't think this addresses the reporter's concerns.

I think that there might be some rough edges around the phrasing of distrusted CA errors, but that overall, they are not overtly misleading. For the most part, I agree that we should handle Legacy Symantec PKI errors the same as any untrusted root. 

The customized Legacy Symantec PKI codes were added to aid in Chrome's gradual distrust of these TLS certificates over the past 13 months and to assist the large number of affected sites in migrating their certificates. The net error codes and console warnings provide technical information to site operators (either through direct Chrome testing or user error reporting) so that they can take action to fix their sites so that future visits by users will no longer show errors. 

We can examine whether altering language for CAs that were once trusted but are being distrusted is worthwhile (as compared to those that have never been trusted), but there are so many edge cases here that it might actually increase user confusion rather than decrease it.

A related change we did make was to make the support URL go directly to a section about Symantec (see  bug 891465 ). That seems like a reasonable middle-ground, since we do know that the interstitial is being shown because it is a Symantec cert so we can customize the "learn more" behavior at least.

Re-triaging this as a feature request for how we handle interstitials for CA-distrust events in the future (per c#12).

[And additionally, marking all Blink platforms where we have full certificate validation control.]