Your connection is not private: read the second line
Chrome shows this screen for at least eight distinct problems. Some are on the server, one is on the visitor's laptop, one is a clock, and one is not a fault at all. The headline is identical in every case, which is why the advice you find online is identical in every case, and mostly wrong.
The useful information is the short string underneath, in grey, that most people scroll past. It looks like NET::ERR_CERT_DATE_INVALID. That string is the diagnosis.
The codes, and what each one means you should do
| Code | Cause | Whose problem |
|---|---|---|
ERR_CERT_DATE_INVALID | Expired, or not valid yet | Yours, unless the visitor's clock is wrong |
ERR_CERT_COMMON_NAME_INVALID | The name requested is not in the certificate | Yours. Usually a missing subdomain. |
ERR_CERT_AUTHORITY_INVALID | The issuer is not trusted | Yours if self-signed, theirs if an antivirus is intercepting |
ERR_CERT_REVOKED | The issuer withdrew it | Yours, and urgent |
ERR_CERT_WEAK_SIGNATURE_ALGORITHM | Signed with something retired | Yours. Reissue. |
ERR_CERT_SYMANTEC_LEGACY and similar | A whole issuer got distrusted | Yours, and it arrives without warning on a certificate that has not changed |
ERR_SSL_VERSION_OR_CIPHER_MISMATCH | No shared protocol or cipher | Yours, or a very old client |
ERR_CERT_INVALID | Malformed, or a chain that does not build | Yours. Usually a missing intermediate. |
Two of these deserve more than a table row, because they are the ones that get diagnosed wrong.
The wrong clock
A certificate is valid between two instants. The browser compares them to the clock on the machine it is running on. If that clock is a year off, a perfectly good certificate reads as expired, and the visitor sees the same red screen as everybody else.
This sounds rare. It is not. It happens on machines whose battery died, on freshly reimaged laptops before they sync, on phones that have been off for months, and on virtual machines resumed from an old snapshot. When a single user reports a certificate error that nobody else can reproduce, ask what date their computer thinks it is before you touch the server.
The reverse also exists and is more embarrassing: a certificate issued with a start date in the future, which happens when the issuing server's clock is ahead. It is valid, it is correct, and it will not work for another six hours.
The missing intermediate
This is the one that produces the most wasted time, because of a property that makes no sense until you have hit it once: the site works in your browser and fails in someone else's.
A certificate chain runs from your certificate up through one or more intermediates to a root the client already trusts. Your server is supposed to send the intermediates. If it does not, a client that happens to have cached that intermediate from another site will build the chain anyway and show no error. A fresh client will not.
So a misconfigured chain works on your laptop, which has visited half the internet, and fails on a colleague's new phone, on a mobile network, and in every automated client. Curl and openssl are fresh clients every time, which is what makes them worth asking:
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
| grep -E 'depth|verify (error|return)'A chain that builds ends with Verify return code: 0 (ok). Anything else is a real problem that your browser is hiding from you.
Reading the certificate the server actually serves
Three fields answer most questions, and they are one command away:
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltNameThe -servername flag matters. Without it you are not sending SNI, so a server hosting several sites on one address will hand you whichever certificate is its default, and you will spend twenty minutes confused by a certificate for a domain you have never heard of.
Read subjectAltName rather than the subject. The common name has been decorative for years; browsers check the alternative names, and a certificate covering example.com but not www.example.com is the single most common cause of the name mismatch error.
The part that concerns anyone watching sites
A certificate that expires tonight looks identical to one that expires in a year, right up until it does not. There is no gradual degradation, no slow rise in errors, no warning in a log. At one specific second, every visitor gets a full-page red interstitial, and the conversion rate of that page is zero.
It is the cheapest outage in this trade to prevent and one of the most common to suffer, because the thing that usually fails is not the certificate. It is the renewal: a cron that stopped, a validation path that a redirect broke, a DNS record that moved. Automatic renewal fails silently by construction, since the thing that would have told you is the thing that stopped running. That failure has its own anatomy, and it is worth reading before you meet it: what actually stops a renewal, and the one signal that catches it.
Which means the only signal worth having is the expiry date itself, read from the live connection, on a schedule, with enough notice to act. Not the renewal job's exit code, not a calendar reminder set when the certificate was issued. The date the server is currently serving.
That is also why the free checker here reports the certificate's remaining days alongside the status code: a site can answer 200 perfectly for the fifteen days before it stops answering to anyone at all. The same blind spot, in a different guise, runs through the nine codes worth knowing.
