Not a bug Chrome cache doesn't change after xenforo renews SSL certificate?

W

wangyu1314

Member
Affected version
xenforo 2.2.x
After my forum SSL certificate is changed from lets's encrypt certificate to sectigo ECC certificate, the SSL cache in chrome that has visited the forum before will not change, it is still let's encrypt, although the website can be connected.
However, vb 3.8.12 of the same configuration environment of the same server also replaces the SSL certificate, from let's encrypt R3 RSA → let's encrypt E1 ECC → Sectigo ECC certificate, each time chrome will immediately update to a new certificate.
So I don't know what the problem is, but it bothers me to bring it up.
 

Attachments

  • 2022-10-30_102539.webp
    2022-10-30_102539.webp
    21.1 KB · Views: 18
  • 2022-10-30_102849.webp
    2022-10-30_102849.webp
    39.3 KB · Views: 18
You may need to restart or dump your server cache after changing the certificate. Xenforo has nothing to do with the SSL config overall, it's at the server level.
 
wangyu1314 said:
But vb 3.8 is everything ok. and I said is client chrome cache. not sever level.
Click to expand...
It's still a server cache or local cache issue, it's not going to be related to XF since it has nothing to do with how the server connects to the client.
The only other thing that it could be is if you have more than one web server (virtual or otherwise) and the ssl config wasn't updated properly for the specific site. That just boils down to a misconfiguration. Did you try other browsers other than Chrome to confirm?

Edit: I checked the domain on Chrome from my PC and it shows...

1667118698384.webp

So it's just your local client issue, the server is correctly configured.
 
ENF said:
It's still a server cache or local cache issue, it's not going to be related to XF since it has nothing to do with how the server connects to the client.
The only other thing that it could be is if you have more than one web server (virtual or otherwise) and the ssl config wasn't updated properly for the specific site. That just boils down to a misconfiguration. Did you try other browsers other than Chrome to confirm?

Edit: I checked the domain on Chrome from my PC and it shows...

View attachment 275700

So it's just your local client issue, the server is correctly configured.
Click to expand...
I tried IE 11, visited the forum after changing the ssl certificate, and after updating the ssl, the ssl cache of IE could not be updated either.
There is only one nginx on the server, two virtual sites. The configuration of the two sites is the same. So I feel weird. Thank you.
I think this bug is easy to reproduce, you can test it.
 
wangyu1314 said:
I think this bug is easy to reproduce, you can test it.
Click to expand...
I get what you're saying, but it's not related to Xenforo, I don't see how it could be since it doesn't deal with SSL certificate settings.

The only issues I've ever had with updating SSL certs is the server caching. I usually make a habit of restarting the entire stack (NGINX, Caching system, etc.) to assure that I can see the updated certs in the browser after uploading new versions. I usually run a quick test here when I update any SSL config settings, including cert renewals to make sure nothing got screwed up.
 
ENF said:
I get what you're saying, but it's not related to Xenforo, I don't see how it could be since it doesn't deal with SSL certificate settings.

The only issues I've ever had with updating SSL certs is the server caching. I usually make a habit of restarting the entire stack (NGINX, Caching system, etc.) to assure that I can see the updated certs in the browser after uploading new versions. I usually run a quick test here when I update any SSL config settings, including cert renewals to make sure nothing got screwed up.
Click to expand...
I modified the nginx config file, commented out
add_header Pragma "public";
add_header Cache-Control "public";
"expires max" change to "expires 3d";

the configure file is:

root /website/hxzylt/xf;
location / {
try_files $uri $uri/ /index.php?$uri&$args;
rewrite ^/sitemap-([0-9]+).xml.gz$ /sitemap.php?c=$1 permanent;
index index.php index.html;
etag off;
#add_header Pragma "public";
#add_header Cache-Control "public";

brotli on;
brotli_types text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon application/octet-stream;

gzip on;
gzip_types text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon application/octet-stream;

expires 3d;
}

Restart nginx, and the new ssl certificate has been pushed to the old cached chrome.
Thank you.
 
For future reference, there’s no caching involved here. TLS certificates aren’t cached by the browser—that wouldn’t make sense.
 

How to clear the SSL state in a browser

You may need to clear your web browser's SSL state, particularly when you install a new SSL certificate. This article shows you how to do so with Mozilla Firefox, Microsoft Edge and Internet Explorer, Google Chrome, and Opera.
www.a2hosting.com www.a2hosting.com

Chrome absolutely does cache certificates and even has a specific option to clear it. I've run into this when renewing certificates.
 
Overscan said:

How to clear the SSL state in a browser

You may need to clear your web browser's SSL state, particularly when you install a new SSL certificate. This article shows you how to do so with Mozilla Firefox, Microsoft Edge and Internet Explorer, Google Chrome, and Opera.
www.a2hosting.com www.a2hosting.com

Chrome absolutely does cache certificates and even has a specific option to clear it. I've run into this when renewing certificates.
Click to expand...
It can theoretically cache some of the certificate’s data, but there’s a handshake process used for encryption and authentication that requires key information to be sent during each connection. If you are seeing the wrong certificate, that cannot be a caching issue: that’s server-side. It’s impossible to establish a TLS connection with the wrong cached certificate; that’s just not how TLS works.

If you’re seeing the wrong certificate but are still able to establish a connection, that’s a server side issue. If the client used the wrong certificate, the server wouldn’t be able to decrypt the stream key; if you somehow managed to bypass the handshake process with the wrong certificate, you’d still be unable to receive a response.
 
I work in IT and have renewed dozens of certs in the last year. I amended the existing process to not use a Chrome check on the new cert because it wasn't reliable - I use a script using openssl instead.

Chrome is not re-downloading the content. As far as I can tell is simply showing you the existing locally-cached copy of the page and showing the (cached) cert details from when it was downloaded. Presumably this would eventually expire, but this issue occurs when you just made a cange and want to see it immediately. There is also a more general issue with server-side changes not being seen in the client - the Chrome cache seems overly aggressive.

If you clear the Chrome cache, you can see the renewed cert correctly as it forces the page and cert to be downloaded again,
 
I've seen the same thing @Overscan mentioned, with every Chrome based browser (Edge, Brave, etc) having this behavior, and I've dealt with countless server setups over the years. Even after flushing the browser cache, I've seen Chrome stubbornly keep the page. I instruct people to both flush the browser cache and restart the browser.
 
Chrome honors cache headers sent by the server, so if you’re encountering that issue, you may want to examine what your server is sending. If the whole page is cached, then yes, you’re going to see the old certificate.

During troubleshooting, if one particular browser seems to be caching inappropriately, try sending a POST request. The response to a POST request generally won’t be cached even if a browser tries to be “smart” and ignore headers.

wangyu1314 said:
expires 3d;
Click to expand...

You should remove that line. It’s not causing the certificate to be cached, but rather the entire response. You are telling browsers it’s safe to cache a page for three days. Furthermore, without appropriate Vary headers, you may be opening yourself up to an information disclosure vulnerability.
 
PaulB said:
Chrome honors cache headers sent by the server, so if you’re encountering that issue, you may want to examine what your server is sending. If the whole page is cached, then yes, you’re going to see the old certificate.

During troubleshooting, if one particular browser seems to be caching inappropriately, try sending a POST request. The response to a POST request generally won’t be cached even if a browser tries to be “smart” and ignore headers.



You should remove that line. It’s not causing the certificate to be cached, but rather the entire response. You are telling browsers it’s safe to cache a page for three days. Furthermore, without appropriate Vary headers, you may be opening yourself up to an information disclosure vulnerability.
Click to expand...
Thank you, I have removed the line "expires 3d;"
 
Back
Top Bottom