A client's SSL certificate expired: what to do
Visitors to a client's website are seeing "Your connection is not private" instead of the site. Most people leave at that warning, so to them the site is down. Here is the order we would work in.
1. Make sure it is the certificate's date
The small error code under the warning says which problem it is. NET::ERR_CERT_DATE_INVALID in Chrome, or SEC_ERROR_EXPIRED_CERTIFICATE in Firefox, means the certificate is out of date. NET::ERR_CERT_COMMON_NAME_INVALID is a different problem: the certificate is valid but does not cover this exact address, often the www or non-www version.
If only one person sees the date error, check the clock on their device first. A computer set to the wrong date shows the same error for a certificate that is fine, and usually for every other secure website too. If the site sits behind Cloudflare, an expired certificate on the host can show visitors a Cloudflare error 526 page instead.
2. Find out who issues the certificate
Renewing it is done wherever it came from, so find that first. Usually it is one of three places: the hosting control panel (often a free automatic certificate, such as cPanel's AutoSSL or Let's Encrypt), a CDN or proxy in front of the site such as Cloudflare, or a certificate bought from the domain registrar. The certificate details in the browser show the issuer.
3. Why automatic renewal stopped
Free certificates usually last 90 days or less and renew themselves, so an expired one usually means renewal has been failing quietly for weeks. The common reasons:
- The domain's DNS points somewhere else now. The site moved host, or a CDN was put in front of it, and the old host can no longer prove it controls the domain.
- The check file cannot be reached. A redirect, a security plugin or a firewall blocks the path the issuer reads to confirm the domain: Let's Encrypt reads
/.well-known/acme-challenge/, and Sectigo, which cPanel's AutoSSL often uses, reads/.well-known/pki-validation/. - A CAA record in the DNS does not allow the issuer. These records name which companies may issue certificates for the domain.
- A paid certificate was not paid for. The card on the account expired, or the renewal went to an inbox nobody reads.
- It renewed, but the server still sends the old one. The web server was not reloaded after the new certificate was issued.
Fix the reason, then renew. Renewing without fixing it gets you another quiet failure at the next renewal.
4. Check the fix from outside
Open the site in a private window, both with and without www. From a terminal on macOS or Linux, this prints the dates of the certificate the server is actually sending:
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -datesIf it works on your computer but fails on some phones, the server is probably sending the new certificate without the intermediate certificate that goes with it. Install the full chain the issuer provides.
5. Tell the client what happened
They will have seen a security warning on their own site, which is alarming. For example:
The warning on the site was an expired security certificate, not a hack. It is renewed and the site is working normally again. I have also fixed the reason it did not renew on its own.
6. Next time, hear about it weeks early
Bionic Uptime reads the certificate of the page it loads on every successful check of an HTTPS website, and emails you 30, 14, 7 and 1 day before it expires. If it expires anyway, visitors cannot reach the site, so we treat it as an outage: confirmed from two locations on two different companies' networks before each person on that website's alert list gets one email. See the exact outage email, or what to check when a site is down for another reason.
3 websites are free, forever, with no card. Looking after several client sites?