Skip to main content

WordPress Hosting & Operations

SSL and HTTPS for WordPress and Drupal: setup, renewal, and common problems

Last updated Fri, Jul 3, 2026

Getting a certificate is the easy part of HTTPS. The problems that fill support queues come afterwards: a redirect loop that makes the admin area unreachable, a padlock with a warning because images still load over http, links in emails pointing to the wrong address. On WordPress and Drupal these almost always come from one thing: the application does not realize it is being served over HTTPS, because the encryption ends in front of it.

Where HTTPS actually ends

On modern hosting, the visitor's encrypted connection usually ends at the CDN or load balancer, which holds the certificate. Traffic from there to the web servers travels inside a private network. The web server receives the request and passes along a header, usually X-Forwarded-Proto: https, saying the original request was secure. If WordPress or Drupal ignores that header, it thinks the visitor used plain http and behaves accordingly.

Certificates and renewal

Certificates on the CDN or load balancer are commonly issued by the cloud provider (for example AWS Certificate Manager) and renew automatically, as long as the DNS validation record stays in place. Certificates bought separately need someone to track the renewal date. Either way, monitor expiry from the outside, so a failed renewal shows up as an alert weeks ahead instead of a browser warning on the day.

To check what a site is presenting:

echo | openssl s_client -connect www.example.gov:443 -servername www.example.gov 2>/dev/null | openssl x509 -noout -subject -dates

The three classic problems

SymptomCauseFix
"Too many redirects" on the site or admin areaThe application sees http, redirects to https, the proxy forwards it as http again, and so onMake the application trust the forwarded protocol header from the proxy
Padlock warning or missing images and stylesMixed content: pages reference http:// URLs for images, scripts, or fontsUpdate stored URLs to https and fix hard-coded links in the theme
Links, emails, or sitemaps use the wrong addressThe site's configured base URL is still http or an old domainCorrect the site URL settings

WordPress specifics

  • Site URLs. The WordPress Address and Site Address settings (siteurl and home) must both use https.
  • Behind a proxy. wp-config.php needs to set $_SERVER['HTTPS'] = 'on' when the forwarded protocol header says https, and only when the request came through your trusted proxy.
  • Stored URLs. Older posts often contain full http:// links to images. wp search-replace 'http://www.example.gov' 'https://www.example.gov' --dry-run shows what would change; run it on Test first, then without --dry-run. It handles serialized data safely, which a raw SQL find-and-replace does not.

Drupal specifics

  • Reverse proxy settings. In settings.php, enable the reverse proxy setting and list the proxy addresses so Drupal trusts the forwarded headers.
  • Trusted host patterns. trusted_host_patterns should list the real domain names, which also protects against host header attacks.
  • Stored links. Body fields with absolute http:// links need updating; relative links avoid the problem in future.

HSTS: the final step

Once everything works over HTTPS, the Strict-Transport-Security header tells browsers to never use http for your site again. Start with a short lifetime, confirm nothing breaks, then lengthen it. Only consider browser preload lists when every subdomain is ready for HTTPS, because preloading is slow to undo.

A quick HTTPS health check

  1. http:// redirects to https:// in a single hop, for both the bare domain and www.
  2. The browser console shows no mixed-content warnings on the homepage and a few inner pages.
  3. Logging in to the admin area works without loops.
  4. Password-reset and notification emails contain https links.
  5. The certificate covers every name the site answers on and has comfortable time before expiry.

If you are moving a site to HTTPS for the first time, also update the address in your analytics, search engine consoles, social profiles, and email signatures, so every link people follow goes straight to the secure version without a redirect.

How eWay handles HTTPS

eWay provisions certificates on the CDN and load balancer, automates renewal, and monitors expiry. TLS 1.2 or later is enforced, HTTP is redirected to HTTPS, and HSTS is enabled. On the application side, eWay configures WordPress and Drupal to trust the proxy correctly, fixes stored and hard-coded http links, and checks for mixed content after migrations and theme changes.

What to include in a support ticket

  • The severity you would assign, P1 to P4 (see severity levels and response times)
  • The URL and exact browser message, or a screenshot
  • Whether the problem is on the public site, the admin area, or both
  • Any recent domain, certificate, or plugin change

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: managing DNS and pointing your domain. More on our WordPress and Drupal pages.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article

Platform Notes

Get practical WebOps and cloud insights in your inbox

We publish articles on managed operations, cloud infrastructure, CMS platforms, government technology, and security, written by engineers who operate these environments every day. No marketing fluff. Unsubscribe any time.

We respect your privacy. No spam, no third-party sharing. Unsubscribe any time.