Google Chrome uses old cert for www domain

Help
#1

Short summary

We first created a www-only cert and some hours later replaced it with naked-domain plus www cert. The web-server is since then only serving the new cert, but it seems the old cert is still used in some cases. e.g Google Chrome still reports the old cert, that will expire soon.

Details

  1. when setting up the server we first created a www-only-certificate id=1607589992: e.g. www.astronovacloud.com
  2. when we noticed the error some hours later, we created a new certificate id=1581932861 which also includes the naked domain : so the new cert has
  • Subject: common name: www.astronovacloud.com
    • Subject Alternative Name:
      • DNS:astronovacloud.com
      • DNS:www.astronovacloud.com
        This 2nd cert works fine and has already been successfully renewed on Aug, 16 (so it is valid until Nov, 14): id=1775908782

But for some reason, it seems that the www-only cert is still used in some cases:

Expiry Bot: the Let’s Encrypt Expiry Bot has sent an e-mail that “www.astronovacloud.com” will expire on Sept, 14th (which must refer to the old www-only cert)

Google Chrome:

  1. when I open a new tab and enter the naked domain: astronovacloud.com chrome shows the correct (new certificate) - expires Nov, 14th
  2. when I open a new INCOGNITO tab and enter the full domain: www.astronovacloud.com chrome shows the correct (new certificate)
  3. when I open a new tab and enter the full domain: www.astronovacloud.com chrome shows the wrong (old certificate):

  • when I now refresh this tab (F5), it still shows the old cert

  • when I refresh with CTRL-F5 I see the new cert

  • now the strange thing is this: we have refreshed with CTRL-F5 everything seems okay, but when we restart Chrome and visit www.astronovacloud.com we see the old cert again! Is there a way to make this change permanent?

So we think the situation is this:

  1. cert bot: we can ignore this message, since it only refers to the old cert that is not in use anymore - the new cert is okay and works
  2. browser: We think that the old cert is just cached by the browser somewhere (because it does work in an incognito tab)
  • we think that this issue only affects users who visited the site before we issued the 2nd correct cert

Can anyone confirm this?

We are of course also worried about what will happen when the old cert really expires:

  • Will Chrome and other browsers then still use the old cert and show that it has expired?
  • Or will the browsers automatically check and find then new cert that uses both naked and www?
  • Is there anything we can do on the server side to fix this?
#2

Edit: removed my previous answer.

I suspect that this might have something to do with your website being a PWA.

Perhaps when your Chrome installation first downloaded your site/manifest, it also recorded the characteristics of the SSL certificate.

Then when you re-visit the PWA, Chrome re-uses that information for its initial offline load.

And when you force a refresh, you actually perform a real SSL handshake and get updated SSL information.

(Alternatively, it might just be that the nature of a PWA just reliably triggers the generic behavior for cached browser responses - if you do not need to revalidate an HTTP resource, avoid opening any SSL connection and show the cached information).

One way to prove this may be to start Chrome with --profile-directory=blah (where your PWA wasn’t already downloaded) and see what happens.

#3

I've run a couple of experiments and I'm pretty sure this ^ is the case.

But what matters to you:

I tried this experiment too.

Chrome will show the stale certificate info with the expiration date in the past, but it will not actually perform any validation, and it won't present an error.

And of course, if you force a reload, validation will be performed against the non-stale certificate info.

1 Like
#4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.