Hmm.  Actually, I just reloaded and now it's coming up with a security warning...

Is it possible that there was a cached version and the symantec warning did not trigger for the cached version?

I don't get a warning either.

Google Chrome	70.0.3538.16 (Official Build) dev (64-bit)
Revision	16ed95b41bb05e565b11fb66ac33c660b721f778-refs/branch-heads/3538@{#306}
OS	Linux
JavaScript	V8 7.0.276.9

Deleted: Screenshot from 2018-09-15 20-54-32.png 333 KB

	Screenshot from 2018-09-15 20-54-32.png 333 KB View Download

Without a chrome://net-internals log to trace when it occurred, we can only go on suspicion. The fact that subsequent loads displayed the error suggest that it's most likely disk cache related - if we successfully load something from the disk cache, we don't re-evaluate certificates, while if we have to check the server (even to reuse a cached entry), then we will potentially use that information.

That said, it looks like there was one Dev cut off the 3538 branch, which would have picked up a switch from source-configured distrust to server-configured distrust (in Firefox terms, "prefs", in Chromium terms, "finch") that may have caused a brief window where the config hadn't propagated yet, allowing it to be trusted (and potentially adding it to the cache). I'll double check the Finch configs, but will mark this as WontFix.

If it's coming from cache and the cert information is available, why is it not checked at that point?

By intentional design, we do not re-validate certificates as they come from the disk cache, nor do we save all connection details relevant to the disk cache.

Consider offline scenarios as an example of why re-validating certificates for disk cached entries is a non-goal, as validating certificates may require online connectivity (e.g. to use AIA to build alternative paths).

I understand why full certificate validation in cached scenarios is undesirable.  But that says nothing about a more limited "affirmative distrust" validation.

The reason I bring this up at all is that in the current setup site operators may not realize they have a cert that needs updating even if they test in a Chrome dev build, if they simply have their site cached...

Yes, we're aware of the trade-offs. However, it's mistaken to believe there's "full" certificate verification and limited affirmative distrust. There are not shades of certificate validation - potential certificate paths are pruned from evaluation during the verification. Displaying affirmative distrust results in false positives - a classic example of this is the distrust of SHA-1 intermediates when SHA-2 versions also existed.

Browser vendors - including Mozilla, in this case - implement distrust as filters on certificate evaluation that work to prune undesirable paths, to see if any valid paths remain. Thus, to get the behaviour you desire, it requires full certificate revalidation on loading from the cache. This is not a desired behavior.

The same argument - that site operators won't know if they have something cached - applies to any other connectivity issue for a server. For example, a site operator won't know if their hosting provider is down if they use the disk cache.