Fix TLS Certificate Name Mismatch Error (2026)

The TLS certificate name mismatch error means the hostname you’re trying to connect to doesn’t match any of the names listed in the server’s SSL certificate. This is a security measure to ensure you’re talking to the right server, not an imposter.

Here are the common culprits and how to fix them:

1. Certificate Issued for the Wrong Hostname

Diagnosis: On the server, check the certificate’s Subject Alternative Name (SAN) or Common Name (CN) fields.
```
openssl x509 -in /path/to/your/certificate.crt -text -noout | grep -E 'Subject:|DNS:'
```
Compare the output (e.g., DNS:example.com, DNS:www.example.com) with the hostname you’re using in your browser or client.
Fix: Obtain a new certificate that includes the correct hostname. If you’re using a wildcard certificate, ensure the hostname you’re connecting to is covered by the wildcard (e.g., *.example.com covers app.example.com but not test.app.example.com). If you have a single-name certificate, you’ll need to request a new one with all necessary hostnames. For example, if you need to access example.com and www.example.com, the certificate must list both.
Why it works: The certificate is the server’s ID. If its ID doesn’t contain the name you’re using to address it, the connection is rejected as potentially fraudulent.

2. Using the IP Address Instead of the Hostname

Diagnosis: Verify if you’re accessing the server via its IP address (e.g., https://192.168.1.100) when the certificate is issued for a hostname (e.g., https://server.local).
Fix: Access the server using its fully qualified domain name (FQDN) that is listed in the certificate. Ensure your DNS is correctly configured to resolve this FQDN to the server’s IP address.
Why it works: Certificates are designed to validate hostnames, not IP addresses (though some older certificates might have IP SANs, it’s best practice to use hostnames).

3. Typo in the Hostname

Diagnosis: Double-check the hostname you’re typing into your browser or client. A simple typo like exmaple.com instead of example.com will trigger this error.
Fix: Correct the typo in your browser’s address bar or your client’s configuration.
Why it works: The TLS handshake compares the requested hostname character-by-character against the certificate’s SAN/CN list.

4. Incorrect Server Configuration (Web Server/Load Balancer)

Diagnosis: Check your web server (Apache, Nginx) or load balancer configuration to ensure it’s serving the correct certificate for the hostname being requested. For Nginx, check your server_name directive and the ssl_certificate path. For Apache, check ServerName and SSLCertificateFile.
- Nginx Example:
```
server {
    listen 443 ssl;
    server_name example.com www.example.com; # Ensure this matches certificate
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    # ... other configurations
}
```
Fix: Update the web server configuration to point to the correct certificate file and ensure the server_name (or equivalent) directive matches the hostnames covered by the certificate. Restart or reload the web server service.
Why it works: The web server is responsible for selecting and presenting the appropriate SSL certificate during the TLS handshake. If it’s configured with the wrong certificate or for the wrong hostname, clients will receive a mismatch.

5. Wildcard Certificate Misuse

Diagnosis: If you’re using a wildcard certificate (e.g., *.example.com), ensure you’re not trying to use it for a subdomain that requires a specific certificate or a different wildcard. For example, a *.example.com certificate does not cover sub.sub.example.com or example.com itself (unless example.com is also explicitly listed in the SANs).
Fix: Ensure your wildcard covers the specific subdomain you’re accessing. If example.com itself is also a hostname you need to secure, it must be listed as a separate SAN entry alongside the wildcard. If you need to secure multiple levels (e.g., app.example.com and api.app.example.com), you might need multiple certificates or a more general wildcard if your CA supports it.
Why it works: Wildcards have specific matching rules. They only match one level of subdomain.

6. Intermediate Certificates Not Properly Chained

Diagnosis: While less common for name mismatches, an incomplete certificate chain can sometimes manifest in unexpected ways, including trust issues that might be misdiagnosed. Tools like openssl s_client can reveal the chain.
```
openssl s_client -connect your.server.com:443 -servername your.server.com
```
Examine the Certificate chain section.
Fix: Ensure your server is configured to serve the full certificate chain, including any necessary intermediate certificates from the Certificate Authority (CA). This is often done by concatenating your server certificate and the intermediate certificates into a single file, typically named fullchain.pem or similar, and configuring your web server to use this file.
Why it works: Browsers and clients need the full chain to trace the certificate’s authenticity back to a trusted root CA. If the chain is broken, the client may not fully trust the certificate, leading to errors.

7. Load Balancer or Proxy Configuration

Diagnosis: If your server is behind a load balancer or proxy (like an Nginx reverse proxy, HAProxy, or a cloud provider’s load balancer), the certificate might be correctly installed on the backend server but the load balancer itself is presenting a different, or no, certificate. Check the load balancer’s SSL/TLS termination configuration.
Fix: Configure the load balancer to either terminate SSL with the correct certificate, or to pass SSL traffic through to the backend servers which then handle the certificate. If the load balancer terminates SSL, ensure its certificate matches the hostname clients are using.
Why it works: The client establishes a TLS connection with the first entity it connects to. If that’s a load balancer, the certificate presented by the load balancer must match the requested hostname.

After fixing these, you might encounter issues with HTTP Strict Transport Security (HSTS) if the site was previously accessed over HTTPS with a valid certificate and your browser now has a cached HSTS policy.

More Deep Dives in Tls Ssl