A company installs a certificate for example.com, but visitors to www.example.comstill see a security warning. At the same time, the CDN does not validate the origin and a form on the home page submits to an HTTP address.
Reinstalling the certificate will not solve three separate faults. The browser error, affected hostname, TLS termination point, and page requests must be checked in order.
What it means
“Not Secure” after an SSL installation can describe several conditions: the requested hostname is missing from the certificate, the chain is expired or incomplete, the page is still served over HTTP, or an HTTPS page loads insecure resources. A form action, proxy mode, or local HSTS state can also change what the browser reports.
The certificate visible to the public may be presented by a CDN or load balancer rather than the WordPress server. Edge TLS, origin TLS, canonical redirects, and mixed content are related, but each has its own configuration and owner.
A realistic WordPress example
In this case, the apex hostname has the correct certificate but the wwwname does not. The CDN terminates the visitor connection, then reaches the origin without verifying its certificate. Once those layers are repaired, the HTTP form action remains as a page-level problem.
Testing the exact public URLs reveals the sequence: first cover every supported hostname, then validate encryption to the origin, and finally correct insecure requests in WordPress content or code.
Why it matters and when to use it
A certificate warning can block logins, payments, forms, and user trust. It can also indicate that traffic is not protected along the full route even though one endpoint displays a valid certificate.
Use this diagnosis whenever a real public URL remains insecure after certificate installation. Start with the browser’s exact error and hostname; do not suppress certificate validation or enable HSTS while the underlying route is still uncertain.
A straightforward route for beginners
- List every public hostname the site is meant to serve, including apex and
wwwvariants. - Inspect the certificate presented for each hostname, including its names, issuer, expiry, and intermediate chain.
- Follow HTTP and HTTPS redirects and confirm that they end at one intended canonical address without a loop.
- Check the WordPress Address and Site Address, then inspect the final page for HTTP resources and form targets.
- Test login, a harmless form submission, and one unaffected page from a clean browser before enforcing the final redirect.
The advanced route
Compare the certificate and SNI result at the public edge with the direct origin connection. Include IPv4 and IPv6, relevant CDN nodes, host-header routing, the proxy’s origin-verification mode, and the system responsible for renewal.
If the public chain is correct but the warning remains, use the browser network and security panels to identify mixed content or an insecure form action. Treat cached HSTS information as a client-side factor, not proof that the server configuration is correct.
Risks, common mistakes, backup, and rollback
Common mistakes include issuing a certificate for only one hostname, redirecting before HTTPS works at the destination, selecting a proxy mode that skips origin validation, and turning off certificate checks to make an error disappear.
Keep access to the previous configuration while changing redirects or proxy settings. Roll back if administration becomes unreachable, hostnames reach the wrong site, the origin cannot negotiate trusted TLS, or the renewal owner is unknown. Do not enable HSTS until every supported route is stable.
How AIOWS helps:
AIOWS SSL Manager
AIOWS SSL Manager presents supported WordPress HTTPS settings, redirect configuration, and mixed-content checks in one place. It can help separate the WordPress URLs and redirect state from certificate and proxy issues outside WordPress.
Use it after confirming the public and origin certificates. Keep a single redirect owner and a recovery path to the administration area, then test direct HTTPS, the HTTP redirect, login, forms, and page resources from a clean session.
AIOWS cannot validate ownership for an external certificate, repair a CDN or origin TLS configuration, change DNS, or make a third-party resource secure. Those layers remain with the certificate, hosting, CDN, and resource owners.
Related AIOWS articles
- Fix Mixed Content in WordPress: HTTPS Error Guide
- Force HTTPS in WordPress Without Breaking the Site
- How to Check WordPress SSL Certificate and HTTPS Health
Conclusion and recommended route
Begin with the exact warning and hostname. Verify the certificate at the public edge, the encrypted path to the origin, the canonical redirects, and the page resources as separate checks. The site is ready only when every supported hostname and critical interaction works in a clean client.
