I actually take back my last comment. After a hard reload, Chrome reloaded the old, expired cert and marked my site in green Secure. When going to Developer Tools, Security Overview, it had a green "This page is secure (Valid HTTPS)". When clicking "View Certificate" it showed me the certificate that expired on August 24 even though today is August 25.

Deleted: Screenshot 2017-08-25 at 7.47.06 AM.png 108 KB

	Screenshot 2017-08-25 at 7.47.06 AM.png 108 KB View Download

I suspect that this is a duplicate of Issue 652642, whereby the resource was cached with a valid certificate and when reused from the cache/ServiceWorker, the certificate originally obtained is displayed. 

That isn't a security issue but instead a functional issue in this corner case.

Can you share any additional information about your site, like a Network Log? https://dev.chromium.org/for-testers/providing-network-details 

Sure. Is there potentially private information in the log? If not, I'll upload it.

And the site is just Outlook Web Access to an Exchange Server. What's particularly weird about the SSL issue is that I have two tabs for the exact same site open - one is the calendar subdirectory of OWA and one is the email inbox of OWA. They're literally the exact same domain (https://mail.MYSITE.com/). The calendar tab shows the correct cert and the mail tab shows the expired one above.

Thank you for providing more feedback. Adding requester "elawrence@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

rsleevi@, would you be the right person to tackle this? Thank you.

I do not believe this represents a Security Bug, and should be WontFix/Working As Intended, but I also am not sure this represents a "Functional" bug either - this is working as designed.

As noted in Comment #2, this is fundamentally a duplicate of Issue 652642, although that was more limited in its description, so I won't dupe it.

There is no requirement in any implementation to limit the maximum cache age of a resource to the lower-bound of (server supplied cache timing, certificate expiration). I am further not aware of any implementation that implements such logic. That would be a significant design change with non-trivial performance impact and the potential to undermine ecosystem security (by encouraging longer-lived certificates to have longer-lived resources).

When a resource is loaded solely from the disk cache (without any server interaction), we display the resource information that was loaded from the cache. When something involves communication with a server (including validating that the cached resource is still usable - such as If-Modified-Since), then we display that information.

Yes, but when I did a Hard Reload and Empty Cache, shouldn't that have loaded the resource from the server and not from the cache? If so, it didn't because the server no longer has the expired cert.

And, as a piece of the functionality, isn't the purpose of the green "Secure" to let the end-user know that the encryption hasn't been tampered with? If so, doesn't displaying an invalid cached cert as Secure invalidate that function since the end-user - me in this case - can no longer know if the connection is, in fact, secure because Chrome is designating a clearly expired cert as "secure", a contradiction that might make the end-user wonder if security has been hijacked in some way?

The encryption was not tampered with when the item was cached to disk, and so it is an accurate representation of how the information was loaded.

With respect to DevTools' "Empty Cache and Hard Reload", that is not necessarily going to ensure all the necessary details are flushed. For example, if within a still running session, you may have performed TLS session resumption, in which the server 'negotiated' with the old certificate on a new connection. This is also valid (and practiced by servers). The chrome://net-export log mentioned in Comment #2 would confirm this.

I see - thanks for clarifying.

I guess my thought, as to functionality, was that if the purpose of the green Secure is to tell the user there's been no encryption tampering, is that functionality undermined by displaying the cached invalid cert as valid? Does the end-user then lose faith in the browser's ability to distinguish between a secure connection and an insecure one?

I mean maybe it makes no difference since I'm guessing most people will see the green Secure and not examine the actual certificate, so perhaps it's more of a philosophical question about communicating security to an end-user and whether seemingly contradictory information - green Secure with expired cert - is allowable as part of that communication or whether that seeming contradiction would undermine user faith in the chain of trust.

One way to resolve that ambiguity is to not display the certificate at all :) 

If I hadn't looked at the cert, I never would've filed this report since my site was green/Secure, so maybe that's genius solution! :)

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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