The padlock is broken and the error says the certificate name is invalid. Nothing is expired, the issuer is trusted, and the certificate works perfectly on another hostname.
That is the whole problem: the certificate is valid, it just does not cover the name in the address bar. Browsers match the requested hostname against the certificate’s subject alternative name list, and yours is not in it.
Read the SAN list first
Before theorizing, look at what the certificate actually claims to cover:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltNameCompare that list against the name you typed, character for character. The answer is usually visible immediately.
The five reasons
| Cause | What it looks like |
|---|---|
| The bare domain is missing | *.example.com is on the certificate, example.com is not. www works, the apex does not |
| Wildcard depth | *.example.com matches www.example.com but never a.b.example.com. Wildcards cover exactly one label |
| Default virtual host | The server did not recognize the requested name and fell back to whatever certificate is configured first, which belongs to a different site |
| Missing SNI | An old client or script did not send the server name, so the server had to guess and guessed wrong |
| The wrong certificate is deployed | A new certificate was issued for a different set of names and deployed to the wrong place |
Common Name is not what is being checked
Worth clearing up, because the error message misleads. Browsers stopped using the Common Name field for hostname matching years ago and use the subject alternative name extension exclusively.
So a certificate whose CN reads example.com will still fail for example.com if that name is not also in the SAN list. The error text mentioning “common name” is a legacy label, not a description of what was checked.
The apex and wildcard trap
This one catches people repeatedly, so it is worth stating plainly.
*.example.com covers www.example.com, api.example.com, and shop.example.com. It does not cover example.com, and it does not cover dev.api.example.com.
If you want the apex and its subdomains on one certificate, both example.com and *.example.com have to be listed. Most issuers do this automatically when you ask for a wildcard, which is exactly why the ones that do not catch you by surprise.
Fix and confirm
Reissue the certificate with the complete name list, deploy it to whichever service terminates TLS for that name, and reload. Then re-run the command above against the name that was failing, plus every other name on the certificate, since adding one name is a good opportunity to drop another by accident.
If the mismatch only happens on some requests, you are probably looking at a load balancer where one node has a different certificate. Certificate expiry, revocation, and deployment covers reading the per-endpoint evidence, and connection and certificate errors covers the neighboring failure modes.