How to Check Whether Your SSL Certificate Covers Both the www and Non-www Versions of Your Site

Your site loads perfectly at example.com, and a visitor who types www.example.com gets a full-screen security warning. Or the other way round. The certificate is valid, it is not expired, and your host insists everything is fine. The problem is narrower than that: your certificate may cover one version of your domain and not the other, and browsers treat those two versions as two completely different names.

www and non-www are two different names

To you, example.com and www.example.com are the same site. To a browser they are two different hostnames, and a certificate is only valid for the exact names listed on it. A certificate issued for example.com does not automatically cover www.example.com, and one issued for www.example.com does not cover example.com. Each version needs its own entry, and forgetting one is one of the most common reasons a site shows a certificate error to half its visitors while looking fine to the other half.

The error usually reads NET::ERR_CERT_COMMON_NAME_INVALID in Chrome. Despite the name, it has nothing to do with the old Common Name field. It means the hostname you visited was not in the certificate's list of names. The most frequent cause is exactly this gap: the certificate covers the www version while someone visits the bare domain, or the reverse.

The list that decides it: the Subject Alternative Name field

Every publicly trusted certificate carries a field called the Subject Alternative Name, or SAN. It is the list of hostnames the certificate is valid for, and since 2017 browsers have used it exclusively. The older Common Name field, the one most people check first, is ignored entirely by modern browsers. A certificate can have a perfect Common Name and still fail if the hostname is missing from the SAN list.

So the check that matters is simple: open the certificate's SAN list and look for both names. You want to see two entries: example.com and www.example.com. If only one is there, the other version of your site is unprotected, and anyone who arrives through it sees a warning.

The wildcard trap

A wildcard entry looks like a shortcut: *.example.com covers www.example.com, shop.example.com, and any other single-label subdomain. But it does not cover the bare domain example.com itself. A wildcard needs a label to fill, and the bare domain has none. The correct pattern for a wildcard certificate is therefore two entries: *.example.com plus example.com. If your certificate lists only the wildcard, visitors who drop the www hit the error.

Wildcards have a second limit: they match one level only. *.example.com does not cover api.staging.example.com, which is two levels deep. That needs its own entry, or its own wildcard for *.staging.example.com. If you use deeper subdomains, check each one the same way.

How to check both versions in two minutes

Run your domain through our SSL Checker. It reads the Certificate Transparency logs, the public records where every trusted certificate must be published, and shows the certificate your site is actually using, who issued it, when it expires, and every name it covers. Look at the names list and confirm both example.com and www.example.com are there.

Then check the other direction yourself. Visit both versions in your browser: https://example.com and https://www.example.com. A padlock on both means both are covered. A warning on one tells you exactly which name is missing. Do this in a private window, or after clearing the cache, so a cached redirect does not hide the result. A redirect from the broken version to the working one can make the problem invisible to you while it is still real for first-time visitors.

While you are there, note the expiry date the checker shows. A certificate that covers both versions but expires next week is a problem of a different kind, and our post on what actually happens when your SSL certificate is about to expire walks through it.

What to do when one version is missing

First, check whether the missing version is one anyone actually uses. If your site redirects all traffic to one canonical version, most visitors never touch the uncovered name. But there is a catch: a redirect from https://example.com to https://www.example.com still needs a valid certificate for example.com, or the browser stops the visitor before the redirect can happen. The safe setup is both names covered, then a redirect on top.

How you fix a missing name depends on how the certificate was issued. If you use Let's Encrypt, it normally includes both versions automatically when either is requested, so reissuing with both hostnames listed usually fixes it. With a paid certificate, the fix depends on the type: single-domain certificates from most providers include both versions by default, while multi-domain certificates need each version added as a separate SAN entry, which may mean reissuing with the extra name included. Check with your provider or host before paying for anything: many will reissue at no extra cost.

If your certificate is a wildcard and only the bare domain is missing, the fix is the same: reissue with both *.example.com and example.com in the SAN list.

What to do first

Run the check now, before a visitor reports the problem. Open the SSL Checker, type your domain, and read the names list: you want example.com and www.example.com both there, plus any subdomain you actually use. Then visit both versions in a private window and confirm the padlock on each. If a name is missing, reissue the certificate with both names listed, and set a redirect from the version you do not use to the one you do, so every visitor lands on the same address. Two minutes of checking now saves you the visitor who never comes back after a security warning.