Fix SSL Certificate Mismatch on Endpoint

You're staring at a big warning that says the SSL certificate doesn't match the site name. It's annoying, and it blocks you from getting to a site you trust. I've seen this a hundred times. Let's fix it.

The Quick Fix (Most Common Case)

This error usually means you're visiting a site using one name (like example.com) but the certificate was issued for a different one (like www.example.com or a totally different domain). The fix is either to access the site using the exact name on the certificate, or to get a new certificate.

First, check the exact domain name you're typing. If you typed example.com but the certificate says www.example.com, just add the www. in the address bar and hit Enter. After you do that, you should see the padlock turn green or the warning disappear. Expected outcome: The connection becomes secure.
If that doesn't work, open your browser's Developer Tools (F12 on Windows, Cmd+Option+I on macOS). Go to the Security tab and look at the certificate details. There you'll see the Common Name (CN) and Subject Alternative Names (SANs). The site you're visiting must match one of those. Write down the names you see.
Now change your URL to match one of those names. For example, if the CN is secure.example.com, change your URL to https://secure.example.com. Reload the page. Expected outcome: The error should go away.

That's the fix for most people. The real issue is that the certificate wasn't issued for the domain you're trying to reach.

Why This Happens

SSL certificates are like ID cards for websites. The browser checks that the name on the ID matches the name you typed. When they don't match, the browser screams at you. This happens for two main reasons:

The server is using a certificate for a different domain. This is common if you're hosting multiple sites on one IP address and the server sends the wrong certificate.
The certificate doesn't include all the domains you use. Maybe the certificate covers mail.example.com but you're trying to reach shop.example.com. The SANs list matters.
You're using an IP address instead of a domain name. Most SSL certificates are issued for domain names, not IPs. If you type https://192.168.1.10 and the cert says my-server.local, you'll get the mismatch error.

The browser is doing its job. It's protecting you from someone pretending to be a site they're not. The fix is always on the server side or in how you connect.

Less Common Variations

You're the Server Admin — Fix IIS or Apache

If you run the server, the fix is different. Here's what to do for the two most common web servers.

For IIS (Windows Server)

Open IIS Manager. Click on your site in the left panel.
Double-click Bindings on the right side.
Select the HTTPS binding and click Edit.
In the Host name field, type the exact domain that matches your certificate. For example, if your cert is for www.example.com, type that here.
Click OK and restart the site. Expected outcome: The site now serves the correct cert for that host name.

I've seen admins skip the host name field and leave it blank. That's a mistake. The server then sends the default certificate, which might not match. Always fill in the host name.

For Apache (Linux)

SSH into your server.
Open your virtual host config file, usually in /etc/httpd/conf.d/ or /etc/apache2/sites-available/.
Look for the <VirtualHost *:443> block. Inside it, check the ServerName directive. That must match the certificate's CN or one of its SANs.
If you need to serve multiple domains, use ServerAlias to list them. For example:
```
ServerName www.example.com
ServerAlias example.com
```
Save the file and run sudo systemctl restart httpd (or apache2). Expected outcome: The error clears for all listed domains.

The Certificate is Self-Signed

If you or your IT team created a self-signed certificate, the browser will always show a mismatch if the domain doesn't match exactly. The easiest fix is to install that self-signed cert onto your machine as a trusted root. But be careful — self-signed certs are fine for internal testing, not for production.

The Date/Time is Wrong on Your Machine

This one's sneaky. If your computer's clock is off by more than a day, the SSL validation fails and can show a mismatch error (or an expiration error). Fix it by syncing your time:

Windows: Right-click the clock -> Adjust date/time -> Turn on "Set time automatically."
macOS: System Settings -> General -> Date & Time -> Turn on "Set time and date automatically."
Linux: Run sudo timedatectl set-ntp yes.

Expected outcome: After syncing, refresh the browser. The error should be gone if that was the only problem.

How to Prevent This

Here's what I tell all my technicians to do upfront so you never see this error again.

Use a wildcard certificate if you have multiple subdomains. For example, *.example.com covers www.example.com, mail.example.com, and shop.example.com. It costs a bit more but saves you headaches.
List all your domains in the SANs field when you order a certificate. If you own both example.com and example.net, put them both in the SANs. Don't rely just on the Common Name.
Check your bindings or virtual hosts every time you change a certificate. I've seen people swap a cert and forget to update the server config. That's the most common cause of this error on the admin side.
Test with an online SSL checker after you make changes. Just search for "SSL checker" and type your domain. It'll tell you exactly what names the certificate covers and if anything's wrong.

That's it. Fix the mismatch by matching the domain to the certificate, or get a new cert that covers all your domains. Then move on with your day.