Two problems are often grouped together as an “SSL error.” Sometimes the browser cannot establish a secure connection at all. In other cases the HTTPS page opens, but an image or script is blocked because it still uses an insecure address.
Read the exact warning and note whether it names the site’s hostname or one resource on the page. That distinction tells you whether to investigate the certificate and TLS connection or the page’s mixed-content URLs.
Follow the matching checks below. A working certificate on one hostname does not automatically cover another hostname or the separate connection from a CDN to the origin.
Guide reviewed: October 8, 2026. Menu labels use English WordPress; provider-specific controls may differ.
Separate connection failures from mixed content
| Visible problem | First check | Next action |
|---|---|---|
| Certificate warning before page opens | Hostname coverage and validity | Review the certificate in the hosting/provider panel |
| ERR_SSL_PROTOCOL_ERROR | TLS connection and network comparison | Check provider activation and connection-path evidence |
| HTTPS page opens, resource is blocked | Exact HTTP asset URL | Correct the source that generates that address |
| CDN reports origin TLS failure | Origin certificate and configured TLS mode | Repair the origin configuration |
| Too many redirects | Scheme changes in the redirect chain | Use the redirect-loop guide |
When the browser cannot establish the secure connection
- Record the exact warning and hostname.
- Check certificate status and covered names in the host or certificate provider’s panel.
- Compare the root domain and required subdomains separately.
- If only one network fails, compare another network without bypassing the warning.
Messages such as ERR_SSL_PROTOCOL_ERROR indicate a problem establishing the TLS connection. Possible causes include certificate configuration, protocol compatibility or interference along the connection path. The message alone does not identify a particular WordPress plugin.
Compare the exact hostname with the certificate’s coverage. The root domain, www and other subdomains may need distinct coverage. A certificate for one hostname does not necessarily cover every address used by the site.
In the hosting or certificate provider’s panel, look at activation and validity, and consider whether a proxy or CDN is in front of the host. If the problem occurs on only one network, a comparison elsewhere can help distinguish the site’s configuration from a local connection issue.
The public certificate and the origin certificate may differ
With a reverse proxy, the visitor connects to the proxy, and the proxy separately connects to the origin server. An HTTPS connection in the browser therefore does not establish that the origin connection is configured correctly.
The provider’s SSL/TLS mode and origin requirements should agree with the host. An invalid or unsuitable origin certificate needs to be corrected for the connection being used. Turning off validation simply to suppress the error leaves the underlying issue unresolved.
If the visible problem is an endless redirect rather than a connection failure, inspect the redirect chain as well. The proxy and origin may disagree about the intended scheme. Adding another redirect without tracing the existing chain can make that disagreement harder to see.
WordPress needs to use the intended HTTPS addresses
Once HTTPS can reach the site, review WordPress Address and Site Address under Settings → General. Their hostnames, schemes and paths should match the actual installation. A site installed in a separate directory may intentionally use different paths.
Settings defined through WP_HOME or WP_SITEURL can override database values. If a migration leaves inconsistent addresses, generated links and redirects may continue using the old scheme or hostname. Keeping a copy of the original settings makes a correction easier to reverse.
A secure page can still request insecure resources
- Open the affected page’s Developer Tools → Console and Network panels.
- Find the mixed-content message or failing resource.
- Copy only the resource address, without private query details.
- Locate its source in post content, a theme option, CSS or a plugin setting.
- Confirm the intended asset is available over HTTPS, then correct that source.
Illustrative example: an old HTTP background-image URL in a theme option will not necessarily be fixed by editing the post body.
Mixed content occurs when an HTTPS page requests resources over HTTP. The browser’s handling varies with the resource and circumstances, so the Console and Network panels are useful for seeing what was upgraded, blocked or failed.
For example, an old image address saved before the HTTPS migration may remain in a post. A background image may instead come from a theme option or custom CSS. An external script can come from a plugin setting. The address shown in the browser helps you locate its source.
Correct that source rather than merely hiding the warning. A replacement URL also needs to serve the intended file successfully over HTTPS. Changing the prefix is not sufficient if the external provider does not offer that resource through a secure connection.
Why the warning can remain after the correction
Compare the address now requested by the browser. If it still contains the old HTTP URL, a stored page response or another source may remain. If the request is HTTPS but fails, investigate that new failure rather than repeatedly replacing the prefix.
A page cache, CDN or browser can retain older HTML containing the insecure address. Once the source is corrected, refreshing the affected cache allows visitors to receive the new version. Compare the resource address actually requested before making more changes.
Some pages use assets that others do not. A clean home page is therefore not enough to validate every post, checkout or embedded form. Revisit the page that originally produced the warning and any other view using the same resource.
What to check before calling the work finished
Open the site’s intended HTTPS hostname and confirm the correct page loads without a certificate or protocol warning. Then check the affected resources and the redirect path. Where a CDN is involved, confirm the host and proxy configurations agree.
A short record of the original message, hostname, insecure resource or certificate issue is useful for future troubleshooting. It turns a vague report that the site is “not secure” into a specific explanation of what failed and what was corrected.
HTTPS references and related WordPress guides
- WordPress Developer Reference: wp_is_using_https()
- Cloudflare: Mixed content errors
- Cloudflare: Troubleshoot ERR_SSL_PROTOCOL_ERROR
- WordPress redirect-loop troubleshooting
- WordPress DNS error diagnosis
Finish with the affected page and resources
Verify the original page loads on its intended hostname, the previously failing resources load securely, and redirects stop at the intended address. For the resource issue, see Cloudflare’s mixed-content guidance. The WordPress General settings reference covers site address configuration.