How to Fix SSL and HTTPS Problems After a WordPress Migration

An SSL warning after a WordPress migration does not automatically mean WordPress is broken. The failure may occur before PHP runs: DNS can lead to the wrong endpoint, the TLS virtual host can serve another certificate, the certificate may omit a hostname, or a CDN can use a different edge certificate. If the TLS handshake succeeds but the page still looks insecure, the problem is more likely redirects, proxy HTTPS detection, or mixed content.

Quick answer: Test the exact hostname externally, inspect the certificate presented on port 443, and verify its names, dates, issuer, and chain. Confirm that DNS and CDN route that hostname to the intended destination. Only then check WordPress home/siteurl, reverse-proxy headers, redirects, and HTTP resources embedded in the page. Fix the first failing layer instead of installing an SSL plugin or issuing certificates repeatedly.

Identify the exact HTTPS symptom

Record the hostname, browser error, time, network, and affected route. Test the apex domain and www separately; a certificate that covers one does not necessarily cover the other. Distinguish these common outcomes:

name mismatch: the certificate does not include the requested hostname;
expired or not-yet-valid certificate: dates or system time are wrong;
untrusted issuer or incomplete chain: the client cannot build a trusted path;
TLS handshake failure: protocol, cipher, SNI, listener, or edge configuration fails;
too many redirects: HTTPS works, but routing layers disagree about scheme or host;
padlock warning or blocked assets: the document is HTTPS but contains insecure requests.

Do not bypass the browser warning on an administrative login. Use a separate diagnostic client and avoid entering credentials until the certificate identity is correct.

Inspect the certificate actually served

Query the public endpoint with Server Name Indication so a shared server selects the intended TLS virtual host:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
curl -Iv https://example.com/

Replace example.com with the real hostname. Check the leaf certificate's Subject Alternative Names, validity period, issuer, and returned intermediates. The certificate file present on disk is not evidence that the public listener is serving it.

If only some users see the error, compare IPv4 and IPv6, multiple DNS answers, CDN points of presence, and clients with different trust stores. A stale node or forgotten AAAA record can produce intermittent failures.

Confirm DNS reaches the intended TLS endpoint

Compare authoritative A, AAAA, and CNAME answers with the migration plan. Determine whether TLS terminates at a CDN, load balancer, control panel, reverse proxy, or the WordPress origin. The certificate must be valid at the endpoint the browser actually reaches.

During propagation, old and new endpoints may both receive traffic. Keep a valid certificate and compatible host configuration on both until the cutover window closes. Do not remove the old endpoint solely because one resolver returns the new address.

Verify hostname coverage and the certificate chain

Confirm every public hostname in use is included in the certificate: apex, www, and any required subdomain. A wildcard such as *.example.com does not cover the apex example.com, and it does not cover multiple label levels.

Configure the server with the full chain expected by its software, not only the leaf certificate. Keep the private key protected and never paste it into a browser test, ticket, log, or chat. A certificate and its private key must match; if they do not, replace the server reference rather than manipulating the key material.

Check the HTTPS virtual host and SNI mapping

On shared IP addresses, the port 443 listener chooses a virtual host using SNI. Verify the requested server_name or ServerName, certificate paths, document root, and enabled-site mapping. A default virtual host can serve a valid certificate for the wrong domain.

Validate the web-server configuration before reloading it, and preserve a known-good copy. A safe reload is preferable to an unplanned restart, but the exact command depends on the operating system and deployment method.

Review the existing certificate before issuing another

If the host uses Certbot, the official Certbot user guide documents the read-only inventory command:

sudo certbot certificates

Confirm the certificate name, covered domains, expiry, and live paths. Avoid repeated forced issuance: it can create duplicate lineages, complicate server references, and encounter certificate-authority rate limits. If the certificate is already correct, fix the listener that serves the wrong one.

Test renewal without waiting for expiry

After the active certificate and server reference are correct, test the established renewal workflow:

sudo certbot renew --dry-run

A successful dry run checks the simulated renewal path; it does not replace verification of the currently served certificate. For HTTP-01 validation, confirm that public port 80 and /.well-known/acme-challenge/ reach the correct webroot. For DNS-01, verify the authorized DNS automation and protect API credentials with least privilege.

Separate CDN edge TLS from origin TLS

A proxied site can have two encrypted connections: browser to edge and edge to origin. Inspect both. A valid edge certificate can hide an expired origin certificate until strict validation is enabled; a valid origin certificate cannot fix a hostname missing from the edge certificate.

Use the CDN's documented encryption mode and prefer authenticated, validated origin TLS. Do not select a mode that sends cleartext to the origin merely to suppress an error. Compare public headers with an authorized origin request using the correct Host name.

Make WordPress recognize HTTPS behind a proxy

When TLS terminates before WordPress, the application may receive plain HTTP internally and believe the visitor used HTTP. This can produce insecure URLs, login-cookie trouble, or an infinite redirect. The official WordPress HTTPS documentation explains that the proxy must pass the scheme information and WordPress must recognize it.

Trust forwarded headers only from a controlled proxy. Do not accept arbitrary client-supplied X-Forwarded-Proto values at an exposed origin. Review the proxy's Host, scheme, and client-address header policy as one design.

Check WordPress URLs without guessing

Read the configured values before changing them:

wp option get home
wp option get siteurl

For a normal HTTPS public site, generated public URLs should use the intended HTTPS hostname. However, a subdirectory installation can legitimately use different values, and WP_HOME or WP_SITEURL constants may override the database. Preserve the original values and change only after confirming the architecture.

Resolve redirect loops one owner at a time

Trace every hop:

curl -IL --max-redirs 10 https://example.com/

Identify whether each redirect comes from the CDN, load balancer, web server, security plugin, or WordPress. A common loop sends HTTP to HTTPS at the edge while WordPress, unaware of the original scheme, sends the request back. Competing apex/www rules can create a second loop.

Choose one canonical host and scheme, correct HTTPS detection, then remove duplicate redirect ownership. The post-migration broken-links guide covers redirect chains and route validation in more detail.

Fix mixed content at its source

Mixed content occurs when an HTTPS document requests a resource over insecure HTTP. Modern browsers may upgrade some requests and block others; the official MDN mixed-content reference describes the distinction. Use the browser Console and Network panel to identify exact URLs and initiators.

Check post content, media URLs, theme options, generated CSS, page-builder data, widgets, fonts, scripts, APIs, and CDN hosts. Update owned resources to HTTPS and replace unavailable third-party dependencies. Do not disable browser protection or add a plugin that hides warnings without correcting stored and generated URLs.

Replace old HTTP URLs safely

Start with a serialization-aware dry run:

wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-run

Review matches before removing --dry-run. Scope the replacement to the intended hostname and back up the database. Search separately for www, escaped URLs, old CDN names, CSS, and environment-specific values. Raw SQL replacement can corrupt serialized plugin and theme data.

Do not enable HSTS during diagnosis

HTTP Strict Transport Security tells browsers to force HTTPS for a period that may outlive the current session. Enable it only after the certificate, all required subdomains, redirects, third-party dependencies, and renewal automation are proven. The includeSubDomains and preload choices expand the failure scope and require a separate readiness review.

If HSTS was already served, fixing the HTTPS endpoint is usually safer than asking users to bypass policy. Do not treat removal of the header as immediate rollback for browsers that cached it.

Validate the complete repair

Test apex and www externally over IPv4 and IPv6 where published.
Verify the served names, dates, chain, and final HTTPS status.
Test the homepage, login, admin, a post, media, forms, checkout, and API callbacks relevant to the site.
Confirm there are no loops, unexpected cross-host redirects, or HTTP assets.
Test both CDN and authorized origin paths.
Run the renewal dry run and review its timer or scheduler.
Monitor TLS, application, and proxy logs after DNS propagation.

The repair is complete only when new clients receive the intended certificate and the application consistently generates HTTPS URLs—not merely when one browser shows a padlock from cache.

Common mistakes

Issuing certificates repeatedly before checking which endpoint serves traffic
Covering www but not the apex domain, or the reverse
Installing only the leaf certificate and omitting required intermediates
Using a permissive CDN mode to hide a broken origin
Trusting forwarded headers from untrusted clients
Fixing mixed content by disabling browser safeguards
Enabling HSTS or preload before renewal and subdomains are ready

When migration support is appropriate

CDN termination, multiple origins, IPv6, multisite domain mapping, or a production checkout makes trial-and-error TLS changes risky. A controlled WordPress migration service can verify DNS, certificates, routing, WordPress URLs, and post-cutover checks within the documented migration scope.

Frequently asked questions

Why does the certificate show the wrong domain after migration?

DNS may reach the wrong server, or the port 443 listener may select its default TLS virtual host because the requested SNI name is missing from the intended host configuration.

Why is the certificate valid but the browser still says the page is insecure?

The HTML can load insecure HTTP images, scripts, styles, fonts, or frames. Inspect the Console and Network panel and correct each resource at its source.

Will changing WordPress URLs install a certificate?

No. WordPress URL settings affect generated application URLs. A valid certificate and HTTPS listener must already exist at the public TLS endpoint.

Why does HTTPS create too many redirects behind a CDN?

The edge and WordPress may disagree about the original request scheme, or several layers may enforce conflicting host and HTTPS rules. Fix trusted scheme forwarding and assign redirect ownership clearly.