OP: Does this also happen to repro on platforms other than Mac? I'm thinking this is not just a Mac issue. Thanks!

I only have access to a the mac platform.
And because the TLS certificate has now been updated to a valid certificate, it is now longer possible for me to reproduce this issue.

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

Adding Needs-TestConfirmation

Test: This bug will be particularly tricky to repro as it requires both an expired certificate and renewal certificate. Please contact the security team if you need assistance in reproing this issue.

 mwullink@Thanks for filing the issue...

@Reporter : As per comment # 0 and comment #2 tried to reproduce the issue using provided url in the comment#2 (As we are getting error> This site can't be reached) also other sites (Not seen Not Secure) , It would be really helpful if a sample URL is provided, so that we can investigate the issue further.

Thanks.!

@phanindra.mandapaka@chromium.org

As suggested in #8, this will be a tricky repro. You'll need to set up a HTTP server and have it registered with an expired cert first and navigate to it with Chrome. After that, you need to apply the renewal certificate and refresh the page.

As per comment #8 and comment #10,the issue requires both an expired certificate and renewal certificate. Hence, requesting someone from UI>Browser>Omnibox>SecurityIndicators>VerboseChip team to look into it for further triaging and adding TE-NeedsTriageHelp label to it.

Thanks..! 

Passing over to net folks.

I'm going to go ahead and mark this WontFix, because based on the description, this is Working as Intended. If the ability to reproduce with additional details occurs, getting a chrome://net-export log will help confirm whether or not this diagnosis is correct.

The reason I say "working as intended" is that the omnibox display considers two factors:
1) Whether you've loaded insecure content into that renderer process
2) Whether or not cached information is being used (such as the memory cache or TLS session resumption or HTTP connection reuse)

Simply changing out a server certificate does not change #1 or #2. Opening a new tab MAY affect #1 (depending on a variety of non-net related policy actions), and for #2, the server would need to have flushed the existing connections and flushed the TLS session cache (many don't on changing certificates; they support 'graceful' shutdown where existing connections and caches are allowed to live while new connections use the new certificate) and the memory cache being flushed (which I don't think there is a declarative way)

Of course, none of #2 matters until #1 has guaranteed a new process, which is generally by closing all existing tabs and opening new tabs (possibly after a few seconds time to allow the old process to shut down?)

There may also be some session resumption interactions. If your server continued resuming sessions from before the certificate change, we'll continue reporting the old certificate, since the server never presented the new certificate to begin with. (Things also get cached in the HTTP cache, though we won't put anything from a certificate click-through into the HTTP cache.)