***** MISSED IMPORTANT PART *********

3. Replace LetsEncrypt with Comodo or similar cert. 
4. Go to testdomain.com in a browser and inspect certificate. Site reports "The connection to this site is non-secure" **** and the inspection still reports the LetsEncrypt cert even though it's been deleted from the server. *****

Changing some labels so that the right team can take a look.

Can you please attach a chrome://net-export log, as per https://www.chromium.org/for-testers/providing-network-details ?

In particular, it's important to understand a bit more what is happening with #3, which may depend on the server - for example, if the server is not flushing TLS session caches, which would cause it to reuse information from the previous certificate. A chrome://net-export log will also help demonstrate what's being loaded from the disk cache, if that's being consulted.

I’ll see what I can do in regards to gathering the data as you requested.
However, I’d like to add more information. I filed this ticket because this
issue occurred during a hosting migration.  Browsers were still recognizing
the old certificate even though the server behind that certificate was in a
different part of the world.

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

[robert@commercecanary.com]:  Friendly ping on comment #3.  We can't make any progress without a log.

Team,

It maybe a bit for me to get a log, I don't change and update DNS and
certificates each day, I was hoping it could be investigated without one.

In the meantime, can the chromium team investigate themselves, while I wait
until my next migration so I can get a new log ?

Sincerely,

Robert

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

We can't investigate anything without information from you. There are a lot of scenarios, some of which are and aren't expected.

To start with though, when you say 'Site reports "The connection to this site is non-secure"', what exactly do you mean? Do you mean that opening DevTools showed something? Do you mean that clicking the "Certificate" option from the page info bubble? Do you mean that the page failed to load and you got a certificate error?

That I can help with, the site fails to load and I receive a certificate
error.

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

Okay, in that case the most likely scenario is that the server continued to resume sessions associated with that expired certificate. (Session resumptions do not send new certificates.) The other caches won't trigger a certificate error.

It shouldn't happen for TLS 1.2 if you replace your certificate at least an hour before it expires (we only allow TLS 1.2 sessions to last for a couple hours), but it does mean that it takes some time for fixes to take, yes.

+jselover, this is what we were talking about with "pre-verify" vs "re-verify". We 
could resolve this by implementing the pre-verify thing, though it's a little bit of a mess with the state machine.

We probably also could get 99% the way there by simply filtering out sessions whose stored leaf certificates have expired, which would be rather straightforward...

Yes, I absolutely agree with you.

I would like add one additional check, if the browser is to throw a warning
which does not allow a user to proceed due to any certificate error, it
should at minimum "refresh" and look for any updated certificate
information prior to sending a user to a "this site is not secure" error.
This causes hosting providers and web developers so much pain, and I bet
it's even an exaggerated problem when a site uses HSTS.

Hopefully, my ramble makes some sense!


Sidebar:  A very similar undesired caching issue occurs with "5xx" errors.
What could be the reason for the browser choosing to present the user with
an undesired response from cache, instead of the corrected one from the
server for "any" use case whether 5xx error, SSL error etc.  No need to
respond to this, but it's a good analogy to the SSL issue.

Note you could avoid all this on your server by simply clearing your session cache or rotating tickets when you replace certificates.

David,

While I agree with your suggestions, the issue came when changing hosting
providers or updating DNS and this would not solve the problem
unfortunately.

That is, unless I'm missing something fundamental here..

Oh, if it came changing hosting providers, it's not the session cache. The other hosting provider will not be able to resume sessions from the first one so the scenario I described would not come up. In that case, the only thing I can think of is the DNS update hadn't yet been fully propagated. Unfortunately, yeah, DNS does that.

A NetLog would confirm.

Question, does the SSL handshake happen before or after session
authentication?

I seem to remember the authentication for SSl comes first, which wouldn’t
give the opportunity to invalidate the cached session.

Robert Duffner | *Founder *
*Commerce Canary*
*Cell:* (219) 880-9355

Session caching is part of the SSL handshake. But if we have a cached session from your previous hosting provider, it doesn't matter because the new hosting provider will simply decline the session (it won't recognize the session ID or ticket) and then it will not matter what certificate is cached in there.

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

> I seem to remember the authentication for SSl comes first, which wouldn’t give the opportunity to invalidate the cached session.

No, that is incorrect. The server accepting session resumption changes the shape of the handshake algorithm, so I'm not sure coming "first" would even mean.

Again, if you ran into this switching hosting providers, ignore everything I said about session caching. It is not the cause.

Again, we need a NetLog to diagnose this. As evidenced by my attempt to diagnose it without one only causing confusion.

Mac triage: WontFix - we are missing a netlog.