'Your connection is not private' on your own website? Why the certificate failed, and the fix

Read the error code first

The big headline is the same for several problems. The code in small text under it, or behind the 'Advanced' button, tells you which one you have. Ask whoever reported it for a screenshot that includes the code, or open the site yourself in a private window.

• NET::ERR_CERT_DATE_INVALID in Chrome, or SEC_ERROR_EXPIRED_CERTIFICATE in Firefox: the dates are wrong. Usually the certificate has expired. See causes one and two.
• ERR_CERT_COMMON_NAME_INVALID in Chrome, or SSL_ERROR_BAD_CERT_DOMAIN in Firefox: the certificate is valid, but not for the address that was typed. See cause three.
• Only one person sees it, on one device: check their clock and their security software. See cause four.
• No full-page warning, but the padlock shows a warning, the address bar says 'Not secure', or images and styling are missing: that is mixed content. See cause five.

Cause 1: The certificate has expired

Every certificate has an end date. Let's Encrypt, which issues the free certificates most hosts install automatically, says its default certificates are valid for 90 days and recommends renewing them every 60 days. When renewal works, you never notice. When it fails, your site keeps running normally until the end date, and then every visitor gets the warning at once.

Mozilla's help puts the order of checks well: if the visitor's clock and time zone are correct, the website's certificate may have expired or been misconfigured. To confirm, open your site in Chrome, click the icon to the left of the address ('View site information') and open the certificate details. The validity dates are shown there. If the end date has passed, you have found the problem.

• Log in to your hosting control panel and open its SSL or certificate section. Most hosts have a button to renew or reissue the free certificate. Run it.
• If you bought a paid certificate, renew it with whoever sold it, then install the new one on your hosting. A paid certificate does not renew itself just because your hosting is paid up.
• If your site sits behind another service that handles HTTPS for you, the certificate is issued there, not on your host. Check that service's dashboard.
• Reload the site in a private window. If the warning is gone there, it is gone for your visitors too.
• If the host's tool reports an error instead of a new certificate, the renewal itself is failing. That is cause two.

Cause 2: Auto-renew is failing quietly

Before a certificate authority like Let's Encrypt issues a certificate, it checks that you control the domain. The most common check, called HTTP-01, asks for a small file on your website. Let's Encrypt's documentation says this check can only be done on port 80, that it follows up to 10 redirects, and that it only accepts redirects to 'http:' or 'https:' addresses on ports 80 or 443. If anything stops it reaching that file, renewal fails, and your old certificate simply runs out.

Two other details catch people out. Let's Encrypt ended its expiration reminder emails on June 4, 2025, so if you were relying on a warning email, none is coming. And certificates are getting shorter: Let's Encrypt has announced its default moves to 64 days on February 10, 2027 and to 45 days on February 16, 2028, and that renewing at a hardcoded interval of 60 days will no longer be sufficient. Anything that renews on a fixed manual schedule will break.

• Your domain points somewhere else. If you moved hosts, or changed DNS records, the check reaches the wrong server and fails. Make sure the domain's records point to the hosting that is trying to renew.
• Port 80 is blocked or redirected badly. A firewall rule that closes port 80, or a redirect that sends the check to an unusual port or a broken page, stops validation. Leave port 80 open and redirect it cleanly to HTTPS.
• The certificate is a wildcard (for example *.example.com). Let's Encrypt says wildcard certificates must use the DNS-01 check, which needs a TXT record added to your DNS. If your DNS is managed somewhere your host can't reach, that renewal fails.
• Fix the cause, then run your host's renew or reissue button again and confirm the new end date.

Cause 3: The certificate doesn't cover www (or the other way round)

To a browser, example.com and www.example.com are two different names. A certificate lists exactly which names it covers. If yours was issued only for example.com, anyone who types or clicks www.example.com gets ERR_CERT_COMMON_NAME_INVALID in Chrome, or SSL_ERROR_BAD_CERT_DOMAIN in Firefox, whose message says the site uses a certificate that is not valid for that particular site.

It often appears right after a renewal or a host move, because the new certificate was requested for one name only, or because one of the two names no longer points to the server. Old links on business cards, Google listings and social profiles keep sending people to the name that isn't covered.

• Check that both example.com and www.example.com point to your current hosting.
• Reissue the certificate so it covers both names. Let's Encrypt confirms that one certificate can contain several different names.
• Pick one main address and redirect the other to it, so every visitor lands on the same name.
• If you use subdomains such as shop.example.com, each one needs to be covered too, either by name or by a wildcard certificate.

Cause 4: It's only one visitor's device

If you and everyone else can open the site and one customer can't, the problem is on their side. Chrome's help lists NET::ERR_CERT_DATE_INVALID together with 'Your clock is behind' and 'Your clock is ahead', and says the fix is to make sure the device's date and time are correct. A phone or laptop with a wrong date treats a perfectly valid certificate as expired or not yet valid.

Chrome's help also lists other local causes for 'Your connection is not private': needing to sign in to a Wi-Fi portal first, an extension, antivirus software that scans HTTPS connections, or a work network that inspects traffic. In that case nothing on your website needs changing. Ask them to correct their clock, try a private window, or try a different network.

Cause 5: Mixed content after renewal or after moving to HTTPS

Sometimes the certificate is fine and the page still looks broken: the padlock shows a warning, Chrome's address bar says 'Not secure', or images, fonts or a contact form stop working. That is usually mixed content. Mozilla's developer documentation defines it as a page loaded over HTTPS that still fetches some resources over plain HTTP.

Browsers handle it in two ways. Images, audio and video linked with 'http://' are upgraded to HTTPS automatically where possible. Scripts, stylesheets, iframes, web fonts and similar files are blocked. So the page loads, but the parts that depend on blocked files go missing, which is why a site can look unstyled or a booking widget can disappear the day you switch to HTTPS.

• Open the page, right-click, choose 'Inspect' and look at the 'Console' tab. Chrome lists each mixed content request with its address.
• Change those links from 'http://' to 'https://'. Mozilla's documentation says the easiest approach is often to replace all 'http://' links with 'https://' and then check that they still work.
• In a website builder or CMS, update the site address setting to the https:// version, so new links are written correctly.
• For embeds from other services, use their HTTPS embed code. If a service has no HTTPS version, it can't be used safely on an HTTPS page.
• Mozilla notes that the 'upgrade-insecure-requests' setting in a Content Security Policy upgrades all requests to HTTPS. It helps as a safety net, but fixing the links is the real fix.

Prevent it next time

Most certificate outages are a renewal that failed weeks earlier with nobody watching. A few habits stop that.

• Write the certificate's end date in your calendar with a reminder a few weeks before, and check after each renewal that the date has moved forward.
• When you move hosts or change DNS, check the certificate on the new setup the same day, for both the www and non-www address.
• Don't renew by hand on a fixed schedule. With lifetimes shrinking to 64 and then 45 days, renewal has to be automatic. Let's Encrypt recommends clients that use ACME Renewal Information (ARI) to decide when to renew.
• Keep port 80 open and redirecting cleanly to HTTPS, so validation can always reach your site.
• After any big change, open the site in a private window on your phone as well as your computer, and check the padlock.

If you'd rather not manage this yourself

The fixes above are made with your host or whoever issued your certificate, and for most sites it's one renewal and a quick check. If you'd rather not manage hosting at all, OneSol builds small-business websites with you on the Max plan ($1 for the first month, then $29/month): your own domain connected, CRM and SEO set up, and we keep it running.