Why a site shows a certificate name error on www or without it

A certificate name error appears when the certificate does not list the exact address visitors typed. The classic case is a certificate for example.com but not www.example.com, or the reverse. Browsers show a warning such as NET::ERR_CERT_COMMON_NAME_INVALID. Reissue the certificate to cover both names, then redirect one to the other.

Why www and non-www are different

To a browser, example.com and www.example.com are two different host names. A certificate lists the names it is valid for, in a field called the Subject Alternative Name. If a visitor reaches a name not on that list, the browser cannot be sure it is talking to the right site and shows a warning — even if the certificate is valid and in date for the other name.

Wildcards do not fully solve it either. A certificate for *.example.com covers www.example.com and shop.example.com, but not the bare example.com, and not deeper names like a.b.example.com.

Check which names are covered

1. Enter each form of the address — with and without www — in the SSL Certificate Checker.
2. Look at “Name matches” and the list of names covered.
3. Note the expiry date and whether the chain is trusted while you are there.

The check runs on this site’s server, because browsers cannot read certificate details from another site; only the domain name is sent, and nothing is stored.

Common causes

• The certificate was requested for one name only. Many hosting panels and certificate tools ask which names to include; it is easy to add just one.
• DNS points www somewhere else. If www is a CNAME to a different service, such as an old host or a page builder, that service presents its own certificate.
• A new domain was added without reissuing. Adding a domain or subdomain to a site does not add it to the existing certificate.
• A CDN or proxy in front of the site serves a different certificate from the one you installed on the server.
• Links to the wrong name. Old links, email signatures or printed material point to a name you never meant to serve.

How to fix it

1. Reissue the certificate with both names, for example example.com and www.example.com. Most automated certificate tools accept several names in one certificate.
2. Make sure both names’ DNS records point at the same server or service.
3. Choose one preferred address and send the other there with a permanent (301) redirect. The redirect only works after the certificate is valid for both, because the browser checks the certificate before it sees the redirect.
4. Re-run the checker for both names, and test in a private browser window.

Subdomains and other names

The same rule applies to every name you serve: mail.example.com, shop.example.com, an old domain you redirect from, or a country domain. Each needs to be on a certificate, even if all it does is redirect. Make a list of every host name that appears in your DNS records and on printed material, and check each one. Names you no longer use are better removed from DNS than left pointing at a server with the wrong certificate.

Other errors that look similar

• Expired certificate — NET::ERR_CERT_DATE_INVALID. Renew it; see checking certificate expiry.
• Incomplete chain — some devices fail while others work. See fixing an incomplete chain.
• Wrong clock on the visitor’s device makes valid certificates look expired or not yet valid.

If a link that should work is malformed — for example with encoded characters in the host name — the URL Decoder splits it into scheme, host and path so you can see exactly which host it points to.

Checklist

• Both www and non-www listed on the certificate?
• Both names resolve to the same place?
• One permanent redirect to the preferred name?
• Checked with and without www after the change?