What Firefox actually says
The explanation is short, and it comes with a genuinely helpful extra detail:
...uses a certificate that is not valid for <host>.
The certificate is only valid for <alt-name>.Firefox naming the host the certificate IS valid for is the most useful thing on the page. Chrome does not hand you that.
Read the name Firefox gives you
That second line is the diagnosis, not an aside. Compare it to the address in your bar.
If it names the same domain with a small difference, such as the bare domain when you asked for the www version, the owner has a certificate that only covers one of the two.
If it names your hosting company, a server name, or a CDN, the site is being answered by a default certificate because the domain was never configured for HTTPS on that server.
If it names a completely unrelated business, stop. That is the case where the warning is doing its real job.
The usual causes
Nearly every case falls into one of these.
- →Only one of the domain and www is covered. The certificate lists example.com but not www.example.com. To a browser those are two different hostnames and there is no partial credit.
- →A shared hosting default certificate is answering. The domain points at a server that has no certificate configured for it, so the server presents its own generic one instead.
- →A new subdomain was never added. shop, checkout, app and similar hosts each need to be covered, either individually or with a wildcard.
- →The site moved, and DNS points somewhere the certificate does not live. A stale record can send visitors to an old server holding an old certificate.
- →A CDN or proxy is in front and was set up for a different hostname than the one people actually type.
- →The certificate lists the name only in the legacy common name field. Modern browsers expect every name in the certificate's list of alternative names, so a certificate without it fails even though a human can see the right name written on it.
Why Firefox and Chrome can disagree
Chrome calls this same fault NET::ERR_CERT_COMMON_NAME_INVALID, under the heading Your connection is not private.
Hostname checking works the same way in both, so if one browser rejects the name, the other will too. Where they do differ is trust. Firefox uses the Mozilla CA store to verify that a connection is secure, rather than certificates supplied by the user's operating system, which is why some Firefox-only certificate failures have nothing to do with the hostname at all. That is explained on our Firefox warning page.
If it is your site, in order
Decide which hostnames you actually want people using, then make the certificate and the redirects agree.
- 1.List every hostname that reaches your site. The bare domain, www, and any subdomain such as shop or app.
- 2.Check what the certificate covers. Firefox already told you one valid name. Confirm the rest rather than assuming.
- 3.Reissue to cover every name you serve, or use a wildcard if you keep adding subdomains. Read what an SSL certificate is if the options are unfamiliar.
- 4.Pick one canonical hostname and redirect the others to it over HTTPS. This fixes the visitor experience and helps search engines at the same time.
- 5.Check DNS points where you think it does. A default hosting certificate answering your domain is a DNS or virtual host problem, not a certificate problem.
- 6.Reload the web server and confirm from outside with our free check, testing both the www and non www versions.
Frequently asked questions
Does this mean I am on a fake site?
It can, which is exactly why the warning exists, but usually it is a configuration mistake. Look at the host Firefox says the certificate is valid for. If it is the same business or its hosting provider, it is a setup problem. If it is an unrelated name, treat the site as untrustworthy and leave.
Why does the site work without the www but not with it?
Because the certificate covers only one of them. A browser treats example.com and www.example.com as two separate hostnames, and a certificate has to name each one it is meant to protect. The owner needs a certificate covering both, or a redirect to whichever one is covered.
Is a wildcard certificate the answer?
Often, if you keep adding subdomains. A wildcard covers many hosts at one level, which saves reissuing every time. Note that it does not cover the bare domain automatically, so that name still has to be included explicitly.
The certificate clearly has the right name on it. Why is it still failing?
Modern browsers read hostnames only from the certificate's list of alternative names and ignore the older common name field. A certificate that names your site only in that legacy field will always be rejected, even though the name is plainly visible when you inspect it. Reissue it with proper alternative names.
Can I just add an exception and carry on?
We would not on a site you do not control, especially for a login or payment. The check that failed is the one confirming you are on the site you meant to visit. Reach the site through its correct address instead, or wait for the owner to fix it.