A WordPress SSL certificate expired warning can block visitors before WordPress even loads. Customers may see “Your connection is not private,” a certificate date error, or a Cloudflare 526 page instead of your website. That can interrupt logins, forms, checkout, API calls, and trust in the business.
Do not hide the warning by switching the site back to HTTP or weakening Cloudflare’s SSL mode. First confirm which certificate is failing and where it is being served. Then renew or replace that certificate, verify the complete chain, and test the real business paths that depend on HTTPS.
This guide gives site owners a safe recovery order. It separates an expired certificate from a hostname mismatch, incomplete chain, mixed content, DNS mistake, or cached edge problem so you can fix the failed layer instead of changing WordPress settings at random.
What to check in the first 10 minutes
Start from outside the logged-in administrator session. Use a private browser window and check the exact public hostname customers use, including whether it begins with www. Record the time, browser message, affected hostname, and any visible error code before changing hosting or CDN settings.
- Open the certificate details. Confirm the expiration date, issued-to hostnames, and issuer shown by the browser. Do not send private keys or account credentials to a support form.
- Test both main hostnames. Check
example.comandwww.example.comif both are meant to work. One can have a valid certificate while the other is missing from the certificate. - Identify the HTTPS owner. Determine whether the certificate is managed by the host, a server panel, Let’s Encrypt or another certificate authority, Cloudflare, a load balancer, or a separate infrastructure provider.
- Check the origin and edge separately. A CDN can show a valid visitor-facing certificate while its connection to the origin server fails. Preserve the current configuration before testing that boundary.
- Protect the business path. If checkout, account login, forms, or customer data are affected, pause risky changes and involve the host or maintenance owner immediately.
WordPress is compatible with HTTPS only after the web server has a usable TLS certificate and HTTPS virtual host. Changing home, siteurl, or FORCE_SSL_ADMIN cannot renew an expired server certificate. The official WordPress HTTPS administration guide explicitly treats server-side SSL configuration as a prerequisite.
Does the warning really mean the certificate expired?
Not always. Browsers use several certificate checks before they trust an HTTPS connection. The displayed warning may point to an expired date, but similar symptoms can come from a certificate that does not cover the hostname, an incomplete certificate chain, a revoked certificate, the wrong origin, or a device clock that is far from the correct time.
| What you can confirm | What it usually means | Next safe action |
|---|---|---|
| The browser shows an end date in the past for the public hostname | The certificate being served to that visitor is expired | Renew or replace it through the system that issued and installs the live certificate |
| The date is valid, but the requested hostname is not listed | Certificate name mismatch | Issue a certificate that covers every intended hostname, then verify redirects |
| Only Cloudflare shows error 526 | Cloudflare cannot validate the origin certificate while using strict validation | Inspect the origin certificate, hostname, chain, and port 443 without weakening the long-term validation policy |
| The page loads, but the browser reports insecure images or scripts | Mixed content rather than an expired certificate | Keep HTTPS active and repair the remaining HTTP asset URLs |
| Only one device reports the date error | The device clock, stale network interception, or local security software may be involved | Compare another device and network before changing the production site |
Cloudflare documents that error 526 can occur when the origin certificate is expired, revoked, self-signed without a trusted route, issued for the wrong hostname, or served with an incomplete chain. That makes 526 an origin-validation problem, not proof that WordPress or a plugin broke.
Find who actually controls the certificate
The fastest safe repair starts with ownership. Many WordPress owners know who hosts the site but not which system issues and installs its certificate. Auto-renewal may belong to the host, an ACME client on the server, a reverse proxy, a managed load balancer, or a CDN. Renewing a certificate in the wrong dashboard can create a valid certificate that never reaches visitors.
Managed hosting certificate
On managed hosting, the provider often issues and renews the certificate automatically. Check the domain or SSL area in the hosting panel and the provider status page. Look for a failed domain-validation or renewal message. Ask support which certificate is currently installed on the live virtual host and whether the renewal job completed.
Let’s Encrypt or another ACME client
An ACME client proves control of the hostname and requests a new certificate. Renewal can fail when DNS points elsewhere, port 80 or 443 is blocked for the selected challenge, a webroot path no longer reaches the expected server, credentials changed, or the scheduled renewal task stopped running. Fix the failed validation path before repeatedly requesting new certificates.
Let’s Encrypt’s certificate documentation explains the issuance and validation system behind automated certificates. A dashboard that says “auto-renew enabled” is not proof that a new certificate was issued, installed, and loaded by the live web server. Verify the serial number or validity dates actually served after the renewal.
Cloudflare edge and origin certificates
Cloudflare can manage the certificate visitors see at the edge while your origin server uses a different certificate for the Cloudflare-to-origin connection. Both paths matter. A healthy edge certificate does not repair an expired origin certificate under Full (strict), and a healthy origin certificate does not help if DNS is sending visitors around the expected proxy.
Do not make “Full” instead of “Full (strict)” the permanent fix for an invalid origin. That may restore a page temporarily, but it removes certificate validation on the origin connection. Repair the origin certificate and return to a verifiable configuration.
Load balancer, reverse proxy, or server panel
The certificate may terminate before traffic reaches the WordPress server. In that case, editing the certificate files on the WordPress host changes nothing. Confirm which device accepts the public TLS connection, which certificate bundle it uses, and whether it reloaded after installation.
Renewing the certificate is only half the fix
A replacement certificate must be issued for the correct hostnames, installed with the required intermediate certificates, attached to the correct HTTPS listener, and loaded by the service that answers public traffic. Owners often complete the first step and assume the outage is over.
Use this acceptance order:
- Confirm the new certificate’s start and end dates.
- Confirm the certificate covers the root domain,
www, and any other public hostname that should use it. - Confirm the server serves the complete certificate chain.
- Reload the web server, proxy, or load balancer only through the provider’s documented method.
- Verify the public certificate from a private browser and a second network.
- Check that HTTP redirects once to the intended HTTPS canonical URL.
- Test WordPress login, forms, checkout, webhooks, APIs, and scheduled jobs that call HTTPS URLs.
If the certificate’s private key may have been exposed, renewal alone is not the right response. Generate a new key through the responsible certificate system and follow the certificate authority’s revocation guidance. Let’s Encrypt publishes a separate certificate revocation guide for that situation. Do not paste private keys into tickets, chat, analytics, or WordPress content.
Do not change these settings just to hide the error
Do not switch WordPress back to HTTP
Changing the WordPress Address or Site Address to HTTP does not make an expired HTTPS endpoint trustworthy. It can also create redirect loops, insecure admin sessions, broken callbacks, duplicate URLs, mixed content, and search-indexing changes. Restore the certificate first, then verify WordPress URL settings against the intended canonical HTTPS address.
Do not disable strict origin validation as the final state
If a CDN cannot validate the origin, find out why. An expired certificate is one possibility; a missing hostname or intermediate certificate is another. A weaker mode can conceal the evidence while leaving the origin identity unverified.
Do not install several SSL plugins
A WordPress plugin can help replace asset URLs or configure redirects after HTTPS works. It cannot issue and install a usable certificate on a server it does not control. Multiple redirect or SSL plugins can add competing rules and make the recovery harder to verify.
Do not clear every cache before recording the failure
Caches do not normally extend an expired certificate’s validity, because the TLS handshake happens before WordPress sends a page. However, CDN routing and edge configuration can affect which certificate a visitor sees. Record the current edge and origin behavior first, then purge only after the certificate and routing are correct.
Prove the complete HTTPS path after recovery
A green homepage is not enough. The outage may have interrupted email callbacks, payment confirmations, third-party integrations, API requests, logged-in sessions, or scheduled tasks. Test the routes that create money, leads, and access.
| Path to verify | Evidence of recovery | Stop condition |
|---|---|---|
| Public pages and canonical URLs | One clean HTTPS load, expected hostname, self-canonical output, and no certificate warning | Stop if root and www disagree or redirects loop |
| WordPress login and password reset | Secure login form, successful session, and expected reset email for a safe test user | Stop if cookies, redirects, or recovery mail fail |
| Contact and lead forms | Saved entry, notification trigger, provider acceptance, and inbox receipt | Stop if the form says success without the expected evidence |
| WooCommerce checkout | Correct total, sandbox payment result, order record, email, and callback or webhook | Stop before live payment if any amount or status is inconsistent |
| External integrations | Expected API response and current logs without certificate validation errors | Stop if an integration requires disabling certificate verification |
The official WordPress Site Health screen can show whether WordPress believes the site uses HTTPS, but it is one check rather than complete proof. Compare it with the public certificate, server or CDN state, browser behavior, and business-path tests.
Why automatic renewal can still fail
Automatic renewal reduces risk only when the complete path is monitored. Common failures include expired domain-control credentials, changed DNS records, a migrated server, a closed challenge port, a removed webroot file, a disabled scheduled task, a certificate issued but not installed, or a web server that never reloaded the new files.
Monitoring should therefore check the certificate served publicly, not only the renewal job’s exit status. Alert early enough for a human to verify the affected hostname and owner. Keep the domain registrar, DNS, CDN, host, and certificate contacts current so the warning reaches someone who can act.
When to call for professional WordPress help
Contact your host or infrastructure owner when the certificate is managed outside WordPress, the origin is unreachable, the renewal job reports a validation failure, or you cannot identify which service terminates HTTPS. Bring the hostname, exact browser or CDN error, discovery time, certificate dates, recent DNS or hosting changes, and any provider incident link.
Professional WordPress help becomes useful when HTTPS recovery also involves redirect loops, mixed content, broken admin access, checkout failures, forms, webhooks, caching, or a migration between infrastructure owners. That work needs coordinated server, CDN, WordPress, and business-path verification rather than one plugin setting.
Webless can diagnose the live certificate path, coordinate the necessary host or DNS action, repair WordPress URL and redirect behavior after TLS works, and verify the paths customers actually use. Ongoing WordPress maintenance can also include certificate monitoring, update checks, backups, and recurring form or checkout tests.
Quick answers about expired WordPress SSL certificates
Can a WordPress plugin renew an expired SSL certificate?
Only if that plugin is part of a hosting or certificate system with permission to issue and install the live certificate. Ordinary WordPress SSL or redirect plugins cannot repair the web server’s certificate by themselves.
Will clearing WordPress cache fix an expired certificate?
No. The browser validates the TLS connection before it receives the WordPress page. Purge caches after the correct certificate and routing are active, not as a substitute for renewal.
Why does Cloudflare work on one hostname but not another?
The two hostnames may have different DNS proxy states, edge coverage, redirects, or origin certificate names. Test each hostname and make the intended canonical path explicit.
Can I temporarily use HTTP?
Do not use HTTP for logins, payments, forms, or customer data. Switching production URLs to HTTP can create security, tracking, SEO, and integration problems. Restore the trusted HTTPS path instead.
How do I prevent another certificate-expiry outage?
Use automated issuance and installation, monitor the certificate actually served publicly, alert more than one responsible person, keep domain and DNS ownership current, and test the renewal path after infrastructure changes.
The safe rule: repair trust before changing WordPress
An expired certificate is an infrastructure failure visible through the WordPress site, not usually a WordPress content problem. Confirm the failing hostname and certificate owner, renew or replace the certificate through the correct system, verify the chain and public endpoint, and then test WordPress and every important business path.
Do not hide the warning with HTTP, weaker validation, or extra plugins. A clean recovery restores the certificate, proves the origin and edge agree, and leaves monitoring in place before the next expiration date.