WordPress HTTPS problems are easier to fix when you separate certificate and TLS failures from WordPress URL settings and mixed-content problems. A browser protocol error, a Not Secure warning, and an image blocked for loading over HTTP can all appear on the same site, but they come from different layers.
Quick diagnosis
- ERR_SSL_PROTOCOL_ERROR: the TLS handshake failed. Check certificate activation, hostname coverage, protocol compatibility, proxy/CDN settings, and network interference.
- Not Secure warning: confirm that WordPress home and site URLs both use HTTPS, then check certificate validity and insecure resources.
- Mixed content: the page itself loads over HTTPS but one or more images, scripts, stylesheets, fonts, or iframes still use HTTP.
Check the HTTPS layer before changing WordPress
If the browser cannot complete the TLS handshake, WordPress may never receive the request. Do not begin by disabling plugins when the browser shows a protocol-level SSL failure.
Check the certificate status, the exact hostname being opened, whether the certificate covers that hostname, and whether a CDN or reverse proxy sits in front of the origin. Cloudflare documents ERR_SSL_PROTOCOL_ERROR as a TLS-handshake failure that can be caused by certificate issues, protocol incompatibilities, or network interference.
Make WordPress home and site URLs consistent
WordPress considers the site to be using HTTPS when both the home URL and the site URL use HTTPS. If one value is HTTP and the other is HTTPS, redirects, cookies, canonical URLs, or asset URLs can behave inconsistently.
Check Settings → General when the dashboard is available. Confirm that the WordPress Address and Site Address use the intended hostname and HTTPS scheme. If constants such as WP_HOME or WP_SITEURL are defined in wp-config.php, make sure they do not conflict with the database values.
Mixed content is a resource problem, not a certificate problem
A page can have a valid certificate and still show security warnings if its HTML requests resources over plain HTTP. Cloudflare’s mixed-content guidance gives the common example of an HTTPS page that still contains an http:// image or script URL.
Use the browser developer console and Network panel to locate the insecure resource. Then fix the source of that URL rather than only hiding the browser warning.
Common sources include:
- old image URLs saved before an HTTPS migration,
- theme or plugin settings that still store HTTP URLs,
- hard-coded URLs in custom CSS or templates,
- external scripts or iframes that do not support HTTPS,
- and CDN or cache layers serving an old version of the page.
Reverse proxies and Cloudflare can create a second HTTPS layer
When WordPress is behind Cloudflare, a load balancer, or another reverse proxy, the visitor-to-proxy connection and the proxy-to-origin connection are separate. A site can therefore have HTTPS working at the browser while the origin connection is misconfigured.
Review the CDN or proxy SSL/TLS mode, origin certificate, redirect rules, and whether WordPress correctly detects the request as secure. Avoid adding conflicting HTTPS redirects independently in WordPress, the host, the CDN, and the web server without checking how they interact.
Safe troubleshooting order
- Record the exact browser error and affected hostname.
- Confirm the certificate is active and covers the hostname.
- Check whether the problem occurs with the CDN/proxy in the request path.
- Verify WordPress home and site URLs use the intended HTTPS address.
- Use browser developer tools to locate any mixed-content resources.
- Review CDN, hosting, and server redirect rules for loops or conflicting schemes.
- Clear caches only after the underlying URL or TLS problem is corrected.
What not to do
- Do not reinstall WordPress to fix a certificate that is not active.
- Do not assume a valid padlock means every page resource loads securely.
- Do not add multiple HTTP-to-HTTPS redirects without tracing the existing redirect chain.
- Do not disable certificate validation simply to make an origin connection succeed.
Official references
- WordPress Developer Reference: wp_is_using_https()
- Cloudflare: Mixed content errors
- Cloudflare: Troubleshoot ERR_SSL_PROTOCOL_ERROR
Bottom line: diagnose the layer first. TLS handshake failures, WordPress URL mismatches, and mixed-content warnings require different fixes. Start at the browser and certificate layer, then move inward to WordPress only after HTTPS can reach the site correctly.