I visit my website using Chrome on macOS Mojave, for example, qa.abc.com, and the SSL leaf certificate is from customer-test.ssl.fastly.net. I recently updated the CNAME record in my DNS for qa.abc.com so that it should point b3.shared.global.fastly.net. When I visit qa.abc.com, it resolves the SSL certificate at customer-test.ssl.fastly.net instead of b3.shared.global.fastly.net.

You would think clearing the cache might do the trick, but nope, whether it's Chrome's incognito mode or clearing its cache, still the same. Then I checked on both Safari, Firefox, and even tried to run the following command in my Terminal:

echo | openssl s_client -connect qa.abc.com:443

with the result being:

Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Fastly, Inc./CN=customer-test.ssl.fastly.net
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA

If I jump onto my brother's Windows 10 machine on the same wifi network, the website correctly pulls the SSL certificate from b3.shared.global.fastly.net. If I access the site via my iPhone 6, it's correctly pulling from b3.shared.global.fastly.net. If I browse on my MacBook via tethering on my iPhone 6, it still shows up as customer-test.ssl.fastly.net.

So, we know that:

  1. It's not related to the browser, since all browsers are affected the same way, including openssl at the command line
  2. It's not related to the network, since other devices on the same network work fine.

I suspect that the mapping between a SSL certificate and a domain is cached somewhere at the operating system level.

Other things I've tried but did not work:

  1. Rebooting the computer by shutting it off and powering it back on
  2. Look for any expired certificates in Keychain Access (yes, already enabled viewing hidden expired certificates), but found nothing related to my website or Fastly, and did not find anything wrong with any of the Globalsign certificates.
  3. Tried to delete CRL and OCSP Cache for GlobalSign, but it's not relevant because /var/db/crls/crlcache.db, /var/db/crls/ocspcache.db, nor ~/Library/Keychains/*/ocspcache.sqlite3 exist in macOS Mojave.

2 Answers 2


There's no caching of SSL-certificates like this. It is not a caching issue on the client.

The problem here is with the server - it presents the wrong certificate (from your point of view).

The reason that some clients see one certificate and others see another is most probably due to CDN and/or load-balancing, which means that you're not really hitting the same endpoint. It sounds likely that the server is using persistent connections (aka sticky sessions) which means that your MacBook sees one thing, but your iPhone and Windows 10 machine another thing.

This is something you need to solve at the server level. It hasn't got anything to do with your Mac as such.


So, it turns out what happened was that I mapped the domain to specific IP in my local /etc/hosts file. It was pointing to a CDN node that was serving up the old certificate. Once I removed the entry, it was pointing to a new node with the correct certificate.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .