SSL Cert Shows Wrong Domain – Quick Fix

When This Happens

You type https://yoursite.com into the browser. Instead of your green padlock, you get a warning. You click through and see the cert is for www.someothersite.com. This is dead common on shared hosting, but also happens on your own server when you add a new domain and forget something. I've seen it most often right after moving a site to a new IP or after renewing a cert that was bound to the wrong IP.

Why It Happens

The culprit here is almost always a server name mismatch. The server is serving the first SSL cert it finds for that IP and port. If you have multiple domains on the same IP (which you do in 2024 unless you're running a dinosaur setup), you need Server Name Indication (SNI) to tell the server which cert to use. If SNI isn't configured right, or if the binding itself points to the wrong cert, the server just picks the default one — which is often the first one it loaded, usually from a different site.

Another common cause: the browser cached the old cert. Browsers don't always re-check certs every time. Sometimes they hold onto a stale cert for hours. Flushing that cache fixes it instantly — but if it's a server-side issue, clearing cache won't do squat.

How to Fix It – Step by Step

1. Check the cert's Subject Alternative Names (SANs)
   Run this in a terminal: openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -text | grep DNS:
   Look for your domain in the output. If it's not there, you've got the wrong cert installed. Full stop.
2. Verify the binding on your server
   On IIS: Open IIS Manager, find your site, click Bindings. The HTTPS binding should show your IP, port 443, and the correct cert in the dropdown. If it's blank or shows a different cert, select the right one and click OK.
   On Apache: Check your vhost config. Look for SSLCertificateFile and SSLCertificateKeyFile. Make sure they point to the right files for that domain. Also confirm the ServerName directive matches your domain.
   On Nginx: Same deal. Check the ssl_certificate and ssl_certificate_key directives in the server block for your domain.
3. Enable SNI if it's off
   On IIS 8+ and newer, SNI is on by default. But on older Windows Server 2012 or earlier, you might need to check the binding's "Require Server Name Indication" checkbox. On Apache and Nginx, SNI is built in — but if you're running a really old OpenSSL version (pre-0.9.8f), update it.
4. Restart the web server
   I know it sounds basic, but after changing bindings or configs, the server needs to reload. On Linux: systemctl restart apache2 or systemctl restart nginx. On Windows: iisreset from an admin command prompt.
5. Clear your browser cache
   Chrome: Settings > Privacy and Security > Clear browsing data. Check "Cached images and files". Set time range to "All time". Clear. Then hard reload the page (Ctrl+Shift+R).

Still Broken? Check These

• Is the cert installed on the right server? If you're behind a reverse proxy or load balancer, the cert often needs to be on the proxy, not the backend.
• Does the cert cover all your domains? Wildcard certs only work for one level deep. *.example.com won't cover sub.sub.example.com.
• Check the certificate store on IIS — sometimes you import the cert but it goes into the wrong store. It should be in the Personal store for the computer account.
• Try a different client — test from a phone on mobile data. If it works there but not from your desktop, it's a local cache or proxy issue.

If none of that works, chances are the cert itself is issued for a different domain entirely. Go back to your cert authority, reissue, and make sure you include all needed SANs. Don't skip that step — I've seen people miss a SAN and then wonder why their site shows a cert for www when they typed mysite.com.