Your Connection Is Not Private: Fix an Expired Certificate

"Your connection is not private": what it means and the short answer

The warning appears when a browser can't trust the certificate your site presents. A certificate is a small file on your web server that proves the site is who it says it is and lets the browser encrypt the connection. Every certificate has an expiry date. When that date passes, browsers stop trusting it and put a full-page warning in front of your site. Chrome usually shows the code NET::ERR_CERT_DATE_INVALID underneath.

The short answer: if the certificate really has expired, you renew it, and on most hosting that is one click or one command. An expired certificate alone is not evidence of a break-in or changed content. The warning does stop most visitors from continuing, so it is worth fixing quickly.

Other problems can produce the same warning. The first is a wrong clock on the visitor's own computer, which can make valid certificates appear expired or not yet valid. The second is a certificate that was issued for a different site name. In that case, check that the certificate covers the exact hostname your visitors use.

Is it my website or my computer? How to tell in two minutes

Step 1: Open your site on your phone using mobile data, not your office wifi, and look for the warning. Then open a big site such as a news site. If other sites load fine and yours shows the warning, the problem is on your side of the fence as the site owner. If every HTTPS site shows a warning, your own clock is probably wrong, so set your date and time to update automatically.

Step 2: Open the LabPuff SSL Certificate Checker, type your domain into the box labeled Domain or website URL, and press Run check. Results are labeled Pass, Warning, Fail or Information. The checker looks at the certificate on port 443, the standard port for secure web traffic. It reports rows named Trust chain, Hostname, Issuer, Valid from, Expires and Days remaining.

Step 3: Look at the Expires and Days remaining rows. On an expired certificate, both show Fail. Days remaining is a negative number, and the Technical details section lists CERT_HAS_EXPIRED. When we ran the checker on a test site with a deliberately expired certificate, Trust chain showed Not trusted while Hostname still showed Matches certificate. That combination means the name is right and the date is the problem. If Expires shows a date well in the future, your visitors are seeing something else. Read the Hostname row next, and ask whether the visitors who complain are on a device with a wrong clock.

Step 4: Save the result as a Markdown report. The checker can export what it found, with the time of the check and a note on its limits. The report starts with a one-line summary, then lists each row with its status and value, and ends with the technical details. It also includes a short prompt you can paste into the AI assistant you already use, which asks it to explain the findings in plain language and to separate confirmed problems from checks that didn't finish. You can send the same file to your host's support instead, so you don't have to retype what you saw. The report is a snapshot from one server at one moment, so treat it as evidence to work from and not as a verdict. Keep it, because after the fix you'll run the check again and compare the two.

Type the exact address your visitors use. The checker inspects the hostname you enter, not the place a redirect would send you, so example.com and www.example.com can give different answers. The checker also does not test revocation, which is a certificate authority withdrawing a certificate early, and it shows a snapshot from LabPuff's servers at that moment.

Why do certificates expire, and why didn't mine renew?

Certificates are issued for a limited time on purpose. Let's Encrypt, a certificate authority, issues default certificates that last 90 days and recommends renewing automatically about 30 days before the end. Many setups do this with a scheduled job, so an expired certificate often means that job quietly stopped working.

Picture a small bakery whose site was moved to a new host last spring. The old server had the renewal job, the new one doesn't, and nobody noticed because the certificate still had weeks left. (This is an invented example, not a documented case.) Then the date arrives and the warning appears.

Help articles on this topic list a few common reasons. The domain's DNS, the public directory of settings for your domain, was changed and no longer points at the server doing the renewing. A firewall or a redirect blocks the check the certificate authority runs to confirm you control the domain. Or the renewal job stopped running and nobody was watching for it.

One more detail catches people. A renewed certificate does nothing until the web server starts using it. On a server you manage yourself, the new file can sit on disk while the running server keeps presenting the old one, until the server is told to reload.

Also, Let's Encrypt stopped sending its expiration reminder emails on June 4, 2025. If you used to rely on that email and now get nothing, that is why.

How to renew an expired SSL certificate, by type of hosting

Before you change anything, write down where your site is hosted, where your DNS is edited, and who issued the certificate. The checker shows the issuer. If you will touch DNS or server settings, copy the current values into a note first. That note is your undo.

A website builder or managed host: you usually can't renew the certificate yourself here. Open the domain or SSL settings in your dashboard and look for a status or a prompt. If nothing helps, send their support the checker result, which shows the expiry date and the error CERT_HAS_EXPIRED.

Shared hosting with cPanel: cPanel's own documentation says to open cPanel, go to Security, then SSL/TLS Status, and select Run AutoSSL. Give it a few minutes, then run the LabPuff checker again. If it doesn't work, send your host's support the checker result and ask why the renewal failed.

A server you manage yourself (a VPS or your own machine) using Certbot: run certbot renew --dry-run first. A dry run does a practice renewal against a test service without saving a new production certificate, and reports errors to investigate. Fix that one reason, then run certbot renew. After it succeeds, reload the web server so it picks up the new files. If you use nginx, that is a reload, not a restart, so visitors connected right now are not dropped.

A certificate you bought separately: sign in to the company you bought it from, start a renewal, and install the new certificate the same way you installed the old one. The details differ by host, so use your host's SSL page, not a general tutorial.

Here is a documented case of the self-managed kind. One site owner ran certbot renew and visitors still saw the warning. The owner had created a wildcard certificate verified by hand, which can't renew itself, and the Apache web server was set to use a different pair of certificate files than the ones Certbot issued. A community helper had them switch to the standard web-based verification and reissue the certificates for the www and non-www names. The lesson from that thread is that renewing the file and using the file are two separate steps.

Here is a second case, from a project rather than a person. One open-source project saw its secure download sites break for about 13 hours when certificates for several of its subdomains expired. Months earlier, one old subdomain had been removed from DNS but was still listed on the certificate. When the automatic renewal ran, it couldn't verify that missing name, failed, and sent no alert. Provisioning a new certificate and attaching it fixed it. If you have deleted any subdomains, check whether they are still listed on your certificate.

One Nginx Proxy Manager user reported that disabling Force SSL temporarily allowed renewal after expiry. Treat that as a report about that setup, not a general requirement: Let's Encrypt follows HTTP-01 redirects to HTTPS without validating the certificate, including an expired one. Check the renewal logs and your proxy's challenge routing first. If your host recommends temporarily disabling a redirect, restore it immediately afterward; visitors may otherwise reach the site without encryption.

How to confirm the warning is gone

Step 1: Run the LabPuff SSL Certificate Checker again on the exact address your visitors use. The expiration result should now show a date weeks or months away. If it still shows the old date, the new certificate is not installed on the server answering for that address. If you saved a report before the fix, save a new one now and compare the Expires and Days remaining rows.

Step 2: If nothing changed, check where the domain actually points. Run the LabPuff DNS Lookup and look at the A records, which give the server address, and the NS records, which name who answers DNS for the domain. Compare the A records, and any AAAA records for IPv6, with your hosting setup. A different address may mean you renewed on the wrong server, or that a CDN or proxy serves the public certificate. NS records identify your DNS provider; they do not identify the web server.

Step 3: Run the LabPuff Website Status checker to make sure the site loads and ends at the address you expect.

Step 4: Open your site in a private browser window and confirm the warning is gone. If the checker is clean but your regular window still complains, try a refresh or clear that browser's cache.

Last, put the new expiry date in your calendar for two weeks before it, and find out how the renewal happens: automatic by your host, automatic by a scheduled job, or by hand. If it is by hand, it will expire again.

When paying for help makes sense

The free route comes first. Ask your host's support whether certificate renewal is part of your plan and have them check the renewal setting. That costs nothing and often settles it.

Paying can make sense in two situations. One is a site with several domains or servers where nobody can say which certificates exist or when they expire. A certificate monitoring service watches your domains and emails you before an expiry, so the problem reaches you before your visitors. Let's Encrypt, which stopped sending its own reminders in 2025, points people to third-party monitoring for this. The other is a server you do not know how to manage, where a managed hosting plan takes certificates and server updates off your plate. If your host already renews your certificate and the checker is clean, you can skip both.

Common questions about the "Your connection is not private" warning

Can visitors still get to my site? That depends on the browser, but the warning is built to make people stop, so plan as if some of them will.

Was my site hacked? An expired certificate on its own does not mean so. It means a date passed. The warning tells you the browser can't vouch for the site, not that anything on it was changed.

Do I have to buy a new certificate? Not necessarily. Ask your host first whether renewal is included in your plan.

How long until the fix shows up? A newly installed certificate is served right away. If you also changed DNS, allow time for old answers to expire, which depends on the record's TTL (time to live, the number of seconds other servers may keep an answer).

It says the certificate is valid, but visitors still complain. Ask them to check their device's date and time. Also check that the address they type matches the name on the certificate.