I don't think there's a meaningful security issue here.

It's possible that the refresh occurs on an existing connection, in which case it seems entirely reasonable that the certificate's trust status isn't re-evaluated.

It's also possible that Chrome is caching the trust status of the certificate chain for some short period of time.

Thanks for the reply! It's not an existing connection. I checked with Wireshark. I forgot if it's a refresh or opened a new tab with the same URL, but it sent a new TLS handshake without TLS resumption (the server doesn't support resumption).

Yup, marking this WontFix/WorkingAsIntended and removing the security labels.

Chrome
- Maintains connections to those hosts (i.e. connection reuse)
- Caches certificate verifications (and errors) for 30 minutes
- Maintains in-memory caches of resources (the Blink memory-cache)
- Does not re-evaluate certificates for on-disk cached resources

Chrome also intentionally does not set monitoring events on the root store. We explored this and found that it led to unreliability (particularly due to 3P middleware for smartcards, but also AV that did not properly propagate events) as well as a lack of cross-system predictability (e.g. it's not possible to watch these events on Linux, and on macOS, they're spuriously generated)

Further, given those last two points I mentioned regarding caching, this also logically flows. That is, unless you're willing to revalidate every resource on loading from the cache, and evicting everything in memory from the cache, the desired properties described cannot be obtained.