What does it mean when the SSL certificate doesn't match the domain name being accessed?

　　To be honest, almost every system administrator and website owner has encountered this problem—they've paid for an SSL certificate and installed it following the tutorial step by step, but when they open their browser, the address bar still shows a big red warning: "Invalid certificate" and "Connection insecure." Clicking on the details reveals "Certificate and domain do not match." At this point, most people are wondering: Where did I go wrong? This article will thoroughly break down this problem. Domain mismatch isn't some mystical issue; there are only a few reasons, and once you understand them, troubleshooting is actually quite quick.

　　I. What is a mismatch? The browser's "identity card" doesn't match.

　　The core function of an SSL certificate is to prove to the browser that "the website you are visiting is indeed the domain name written on the certificate." When a Certificate Authority (CA) issues a certificate, it writes the domain name information into two core fields of the certificate—Common Name (CN) and Subject Alternative Name (SAN).

　　When you visit a website, the browser does one thing: it compares the domain name in the address bar with the domain name recorded in the certificate. If they don't match, the browser will determine "authentication failed," directly display a warning, and block the user's access.

　　This mechanism is actually not difficult to understand—a certificate is like a website's "ID card," clearly indicating its "exclusive domain name." If the domain you're accessing isn't on the certificate's "allowed list," the browser won't recognize it.

　　II. Common Mismatch Scenarios: How Many Have You Encountered?

　　Scenario 1: The War Between Naked Domains and www Domains

　　This is one of the most common situations. You've applied for a certificate for example.com, but the user enters www.example.com—the browser checks the certificate and finds that www.example.com isn't in the certificate record, resulting in an error.

　　The reverse is also true—if the certificate is bound to www.example.com, but the user accesses the naked domain example.com, it will still result in an error. Many beginners don't think clearly about "how users will actually access my website" when applying for a certificate, resulting in this pitfall.

　　Scenario 2: Trying to Cover Multiple Subdomains with a Single Domain Certificate

　　A single domain certificate only protects one domain. You deploy the example.com certificate on blog.example.com and shop.example.com—these three are completely different domains in the browser's eyes, so certificate mismatch is almost inevitable.

　　Scenario 3: Incorrect Level of Wildcard Certificate

　　A wildcard certificate looks like this: *.example.com. It can cover first-level subdomains like www.example.com and shop.example.com, but not second-level subdomains—for example, a.shop.example.com. Also, some wildcard certificates don't cover bare domains by default; you need to confirm this.

　　Scenario 4: Changing the Domain, but Continuing to Use the Old Certificate

　　After changing the domain, the original certificate is already bound to the old domain. The new domain is not within the certificate's coverage, and the browser will directly report an error. More specifically, once the main domain changes, the original certificate can no longer be used and must be reapplied for.

　　Scenario 5: Mixing IP Addresses and Domain Names

　　Some older certificates were issued to IP addresses, but browsers generally no longer trust IP certificates. Deploying an IP certificate on a domain site will also trigger a mismatch.

　　III. How to Troubleshoot? Three Steps to Locate the Problem

　　Step 1: Check the browser error message. Click the lock icon in the address bar to view the certificate details, paying close attention to the domain names listed in the "General Name (CN)" and "Subject Alternate Name (SAN)" lists. Compare these domain names with the domains you actually access; discrepancies indicate a problem.

　　The second step is to confirm the type of certificate you purchased. Single-domain, wildcard, and multi-domain certificates each cover a different range of domains.

　　The third step, if you have multiple subdomains, check the coverage level of the wildcard certificate. *.example.com only covers one subdomain, while a.b.example.com exceeds the coverage limit.

　　Ⅳ, how to solve the problem? Address the root cause.

　　If you want to use both the bare domain and www: When applying for the certificate, include both example.com and www.example.com in the SAN list, or configure 301 redirects to unify all traffic to one version.

　　If you need to protect multiple subdomains: If you have few subdomains, choose a multi-domain certificate; if you have many subdomains and will continue to add them, choose a wildcard certificate.

　　If your main domain has been completely changed: Apply for a new certificate. Old certificates cannot be used on new domains.

　　Insufficient wildcard hierarchy: Either apply for a separate certificate for the second-level subdomain, or use a combination scheme such as "multi-domain wildcard certificates".

　　Check the certificate chain for completeness: Mismatch issues sometimes occur together with certificate chain problems. Ensure the server is configured with a complete certificate chain—endpoint certificate + intermediate certificate.

　　V. Several easily overlooked details

　　The certificate and private key must also match. A correct domain name is not enough; the certificate and private key must be a pair. Use OpenSSL to calculate the MD5 values ​​of the certificate and private key separately. If they are different, it means there is a misconfiguration.

　　The server configuration file path must be correct. The file paths pointed to by `ssl_certificate` and `ssl_certificate_key` in Nginx must be correct. After making configuration changes, remember to check the syntax with `nginx -t` and then restart the service.

　　Incorrect system time can also cause problems. If the server time is significantly off, it may cause the certificate to display "not yet effective" or "expired," and errors related to domain mismatch may appear simultaneously. Using an NTP service to synchronize time can avoid this problem.

　　In summary, the core reason for SSL certificate and domain mismatch boils down to one thing: the domain recorded in the certificate is inconsistent with the domain you are actually accessing. The manifestations vary—differences between bare domains and www, a single domain not covering subdomains, insufficient wildcard levels, and not changing the certificate when changing the domain—but the root cause is the same.

　　Solving the problem is not complicated: First, figure out which domains you need to protect, then buy the correct type of certificate. Before buying, confirm the coverage scope, and after deployment, check the certificate details in a browser. Spending ten minutes doing these steps can save you a lot of trouble later.