Browsers report certificate problems with messages that name the cause fairly precisely, and the message is worth reading before doing anything. Each one points at a different fix, and the most common mistake is reissuing a certificate when the problem was never the certificate.
This is a lookup: the warning, what it means, and what to do.
First, check what is actually being served
Before trusting a browser, ask the server directly:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates
That prints which domain the certificate covers, who issued it, and its validity dates. Those three facts resolve most problems immediately.
Your browser caches certificates and intermediates, so it is the least reliable place to diagnose from, and it is why a site can work perfectly for you and fail for everyone else.
Your connection is not private / NET::ERR_CERT_DATE_INVALID
The certificate has expired, or its start date is in the future.
Check the dates with the command above. If expired and AutoSSL manages it, renewal has been failing quietly: usually because the domain no longer resolves to this server. Fix that first, then run AutoSSL.
If it is a commercial certificate, nobody renewed it. Renewing your SSL certificate explains both paths, and the fastest route back is often letting AutoSSL issue a free certificate immediately.
A start date in the future usually means the server's clock is wrong, not the certificate.
NET::ERR_CERT_COMMON_NAME_INVALID
The certificate does not cover the name being used.
Almost always www versus the bare domain. A certificate for example.com does not cover www.example.com unless both were included.
Check what it covers with the command above and reissue including every name the site answers on. Subdomains need explicit inclusion too, unless you hold a wildcard.
NET::ERR_CERT_AUTHORITY_INVALID
The browser cannot trace the certificate back to an authority it trusts.
On a normally issued certificate this means the intermediate chain. The CA bundle was not installed. The distinctive symptom is that the site works in your browser, which cached the intermediate from some other site, and fails on other devices.
Reinstall through SSL/TLS then Install and Manage SSL, pasting the CA bundle into its field. The vendor provides it alongside the certificate.
The same error appears for a self-signed certificate, which no browser will ever trust. Self-signed certificates are for internal testing only.
Padlock with a warning triangle
Not a certificate problem. The certificate is fine and the page is requesting some resources over HTTP.
Reissuing will not help. Open the browser console, which names every offending URL, and fix those. Fixing mixed content warnings walks through doing it without corrupting serialized settings.
ERR_TOO_MANY_REDIRECTS
Also not a certificate problem. Two redirect rules are sending the visitor back and forth, typically a server rule forcing www while the application is configured for the bare domain.
Make every layer agree on one form: the redirect rule, the application's site address, the sitemap. Forcing HTTPS deals with it.
A caching plugin also forcing HTTPS alongside an .htaccess rule is the other common version.
AutoSSL keeps failing
Verification requires the authority to reach the domain over HTTP at a specific path. Three things block it.
The domain does not resolve here. By far the most common. Check with dig example.com and compare against your server address.
A redirect intercepts the verification request. An aggressive rule that redirects everything can catch the validation path.
The domain was removed from AutoSSL's list or excluded during a previous failure.
Fix the cause, then rerun. Repeated retries against an unfixed cause fail identically each time.
Works on desktop, fails on mobile
Almost always the missing CA bundle again. Desktop browsers are more likely to have the intermediate cached; phones are not.
It can also be an old device with an outdated trust store, which is genuinely nothing you can fix from the server side.
Certificate is valid but the site shows a different site
Not a certificate problem. The domain resolves to the server but is not bound to the right account, so the server answers with whatever is at that address by default.
Check the account's document root and that the account actually holds that domain.
A working order
- Read the exact error instead of the general shape of it.
- Query the server with
openssl, not your browser. - Check dates, covered names, and issuer against what you expect.
- Test from another device or network before concluding anything.
- Only then reissue, and only if the certificate is genuinely the problem.
Steps two and four are the ones that save the most time. Most certificate incidents that look mysterious are a cached browser or an intermediate that was never installed.
Browser warnings are deliberately vague. One command shows exactly which certificate the server sent, for which names, expiring when. How to Check a Certificate from the Command Line goes into it.
An error only one device shows, on a site that works everywhere else, usually has one explanation. There is more in Why a Certificate Is Trusted and What a Root Store Is.
When a browser accepts the site and a script refuses it, the two are verifying differently. How to Fix Certificate Errors in Scripts and API Clients deals with the three causes.