This probably should be treated as a functionality bug and not a security bug, unless you didn't first click through a certificate warning in a top-level browser window.

The secure.ecommerce.aliant.net site in question has a long-lived SHA-1 certificate expiring in 2017, and thus it triggers the 
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM error. If you click through the error in a top-level tab, the content loads.

In Chrome 57, the DevTools properly show that the certificate is bad.

NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM

Deleted: Chrome57DevTools.png 66.4 KB

	Chrome57DevTools.png 66.4 KB View Download

I didn't click through an error. The only difference is I loaded the page containing the iframe over http first, and then https to see if the Warning showed up on the top-level tab.

I just verified with incognito mode a click through warning isn't displayed.

Deleted: Screen Shot 2017-01-03 at 12.36.41 PM.png 150 KB

	Screen Shot 2017-01-03 at 12.36.41 PM.png 150 KB View Download

Ah, this is probably "By-design" for Chrome 55; further restrictions against SHA-1 went into Chrome 56 and 57.

Per the end of https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html, from Chrome 41 to Chrome 55, navigation to a site with a 2017-expiring SHA-1 certificate gets the strikethrough in the omnibox but no warning interstitial page. The post notes that such content is deemed "Active Mixed Content" and the DevTools do indeed show the Mixed Content UI treatment, although they do leave the weakly-secured origin in the list.

As the behavior is much stricter in Chrome 56 and the UI behaves in a more correct way, I'm inclined to "Won't Fix" this for Chrome 55.

Deleted: Chrome55.png 88.6 KB

	Chrome55.png 88.6 KB View Download

So Chrome 56 will display a click through TLS error on the page in the original report?

I do wonder how many people have attempted to work around 2017 expiring SHA1 certificate errors by hosting the page inside of an iframe.

> So Chrome 56 will display a click through TLS error on the page in the original report?

Yes. https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html

> I do wonder how many people have attempted to work around 2017 
> expiring SHA1 certificate errors by hosting the page inside of an iframe.

We'll find out shortly (as Chrome 56 gets to stable around the end of the month), but telemetry data suggests that the number is small.

Chrome 55 allows navigation to SHA-1 sites without a blocking page; the DevTools' misleading UI is comparatively minor issue as relatively few users open the tools. Notably, the omnibox does revoke the lock because the weakly-secured content is deemed "Mixed content."

I've confirmed that this scenario behaves as expected in Chrome 56 (SHA-1 pages trigger interstitial blocking, and appropriate notices appear in the Developer Tools), so resolving "Won't Fix".

Thanks for pointing this out!