How to fix SSL certificate errors: Not secure, expired, redirect loops

The short version

• Most SSL errors are fixed by whoever supplies your certificate: your builder, your host or Cloudflare. You rarely need to buy a new one.
• “Not secure” means the page loads over plain HTTP. Turn on the free SSL your builder or host includes, then redirect HTTP to HTTPS.
• An expired certificate usually means automatic renewal broke. Certificates issued since March 15, 2026 last at most 200 days, so renewal must be automatic.
• Cloudflare and “too many redirects”? Switch the SSL mode from Flexible to Full (strict).

Which error, and who to ask

An SSL certificate lets browsers open your site over HTTPS (see HTTPS and TLS). Find your error, then its section below.

Your DNS provider is whoever runs your DNS settings, usually your registrar or Cloudflare.

“Not secure”: the site loads over plain HTTP

Chrome Help says “Not secure” means the connection is not private, so others may see or change what visitors send. Safari shows “Not Secure” for sites using HTTP instead of HTTPS. Firefox shows a padlock or shield with a red strike.

Since version 154, Chrome also asks visitors before it opens a public site over plain HTTP.

1. Find out who hosts the site: a website builder or a web host.
2. On a builder, check that your domain is connected and pointed the way the builder asks. Wix needs a paid plan to connect a domain, then creates the certificate itself. Then give it time. Squarespace says SSL changes can take up to 48 hours, Shopify up to 48 hours for a domain bought elsewhere, WordPress.com up to 24 hours, and GoDaddy’s builder up to 30 minutes after you republish.
3. On a host, turn on the free SSL in your control panel. Most do it for you; Bluehost says its free SSL must be activated by the customer.
4. Turn on your host’s HTTP-to-HTTPS redirect (often called “force HTTPS”), so old http:// links land on the secure page.
5. On WordPress, make sure WordPress Address (URL) and Site Address (URL) under Settings, General both start with https://.

What each builder and host includes is on our SSL by platform page.

Expired certificate (NET::ERR_CERT_DATE_INVALID)

Every certificate has an end date. Certificates issued since March 15, 2026 can last at most 200 days. That drops to 100 days from March 15, 2027 and 47 days from March 15, 2029. Free Let’s Encrypt certificates last 90 days (64 days from February 10, 2027). So this warning usually means automatic renewal stopped working.

1. Check the clock first. Chrome Help says this error can appear when the device’s date and time are wrong. If only one computer sees it, fix that computer’s clock.
2. Click the icon left of the web address (Chrome swapped the padlock for a “tune” icon in version 117) to see the site’s connection details, or ask your provider for the end date.
3. If your builder or host supplies the certificate, ask them to reissue it. Check that your DNS still points to them. Webflow renews only while DNS stays pointed to Webflow, and Kinsta renews only while its _acme-challenge record stays in your DNS.
4. Bought a certificate? Reissue and install it. Namecheap says its certificates should be reissued (free) every 200 days to avoid an outage. GoDaddy reinstalls its self-managed DV certificates for you only on GoDaddy-registered domains; elsewhere you install each reissue yourself.
5. On your own server, check that port 80 is open. Let’s Encrypt’s most common check (HTTP-01) runs only on port 80, so a blocked port stops renewal.

Name mismatch: the certificate does not cover this address

A certificate lists the exact names it covers. If a visitor types an address that is not on the list, the browser warns.

Typical gap: example.com is covered but www.example.com is not, or the reverse. A wildcard such as *.example.com covers www.example.com, but not example.com itself or a.b.example.com. Cloudflare’s free Universal SSL covers the root domain and first-level subdomains; deeper ones need Total TLS or an advanced certificate. See certificate types.

1. Note the exact address that shows the error.
2. Add that name (for example www) to your domains at the builder or host so the next certificate includes it, or redirect it to your main address.
3. Once the new certificate is live, test in a private window.

Too many redirects with Cloudflare (ERR_TOO_MANY_REDIRECTS)

Chrome Help says this error means the page tried to redirect too many times. With Cloudflare in front, its docs name a common cause: in Flexible mode, Cloudflare talks to your server over plain HTTP. Your server sends it back to HTTPS, and the loop never ends.

Full uses HTTPS to your server without checking its certificate. Full (strict) also checks it is valid: use that one.

1. Make sure your host has a valid certificate on the site. Its free one is fine, and Cloudflare’s own Origin CA certificate also works with Full (strict).
2. In the Cloudflare dashboard, go to the SSL/TLS Overview page and choose the Full (strict) encryption mode. If Automatic SSL/TLS is on, pick the custom option first.
3. Reload. If one browser still loops, delete that site’s cookies, as Chrome Help suggests.

Mixed content: parts of the page break on HTTPS

MDN defines mixed content as an HTTPS page that loads files over plain HTTP. Browsers upgrade HTTP images, video and audio to HTTPS, and block HTTP scripts, stylesheets, iframes and web fonts. If an upgraded image, video or audio file is not available over HTTPS, Chrome does not load it.

1. In Chrome, right-click the page, choose Inspect and open the Console tab. Mixed-content warnings name each http:// file.
2. Change those links to https://. On WordPress, which we build on every week, the usual culprits are old image links in posts, theme settings and custom code. A search-and-replace plugin can change http://example.com to https://example.com across the site. Take a backup first.
3. On a builder, check custom code and embed blocks. Replace any http:// address, or remove embeds with no HTTPS version.

HSTS: why visitors cannot click past the warning

HSTS (HTTP Strict Transport Security, RFC 6797) is a setting your server sends that tells browsers to use only HTTPS for your site for a set number of seconds (max-age). RFC 6797 says the browser must end the connection on any certificate error and should give no way to click past it. So a broken certificate locks everyone out until it is fixed.

Strict-Transport-Security: max-age=31536000; includeSubDomains

1. Fix the certificate itself, using the sections above. Visitors have no workaround.
2. Add includeSubDomains only if every subdomain has working HTTPS.
3. Think twice about the HSTS preload list. It needs a max-age of at least 31536000 seconds plus includeSubDomains and preload, and the site warns that removal is hard and takes months to reach Chrome users.

CAA record: the certificate will not issue or renew

A CAA record is a DNS setting that lists which certificate authorities (CAs, the companies that issue certificates) may issue for your domain (RFC 8659). Every public CA must check it first. With no CAA record, any CA may issue. With one that leaves out your host’s CA, new certificates and renewals fail. WordPress.com and GoDaddy both list CAA records as a reason free SSL fails to activate.

1. At your DNS provider, look for any records of type CAA.
2. Delete them if unneeded. To keep them, add the CA your host or builder uses, with the exact value they give (issue for normal certificates, issuewild for wildcards).
3. Ask your host or builder to retry the certificate.

Error keeps coming back? See when to hire help, free vs paid SSL or the SSL certificates hub.

Sources: Google: Not secure, error codes, Chrome 154, HTTPS by default, lock icon, auto-upgrade. Mozilla. Apple. MDN. CA/Browser Forum: Baseline Requirements. Let’s Encrypt: FAQ, rate limits, challenge types. Cloudflare: redirects, Universal SSL, Origin CA. RFC 6797, RFC 8659, RFC 9525. Platforms: Wix, Squarespace, Shopify, WordPress.com, Webflow, GoDaddy builder, GoDaddy SSL, Bluehost, Kinsta, Namecheap.