SSL redirect loop using WordPress HTTPS Plugin

I’m using WordPress in a NginX server proxying to an apache server which serves the pages. Recently we wanted to force the use of SSL at least in the Admin section, so we installed the WordPress HTTPS plugin. The server sections in NginX are properly configured, but when I activate the “Force SSL for admin” option I fall on a redirect loop.

I don’t think that it’s a cookie issue. If you need more info, I’ll pass it to you.

Related posts

Leave a Reply

3 comments

  1. I recently struggled with a similar issue, so I’ll offer a couple of additional pieces of information for people who search for this question.

    1. The first step you should take when trying to force SSL for Admin of your site is to follow the directions in the codex . This means defining the FORCE_SSL_ADMIN option in your wp-config.php file.
    2. Be sure to take note of the warning in the codex that this edit needs to be above the /* That's all, stop editing! Happy blogging. */ line.
    3. There are many possible reasons why this could give you a redirect loop, but they all boil down the fact that WordPress’ is_ssl() function is returning false. For example, you may be running behind a reverse proxy that is doing SSL offloading. If that’s the case, then your users enter https://yourwordpresssite, but the SSL offloader handles the decryption and by the time your server receives the request, the request is no longer SSL, and your server sees http://yourwordpresssite. If you’re stuck here, again the codex has good advice, assuming your reverse proxy is properly configured. See the instructions here: (http://codex.wordpress.org/Administration_Over_SSL#Using_a_Reverse_Proxy).

    If that still doesn’t work, then your reverse proxy may not be setting the HTTP_X_FORWARDED_PROTO header. Unfortunately, none of this stuff is standardized, and there’s more than one way to indicate that SSL offloading has taken place. The way used by our load balancer (Citrix Netscaler) is with the header Microsoft created called Front-End-Https. You can see this header as one of the common non-standard response headers listed on wikipedia here: (http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Common_non-standard_response_headers). Note that by the time your server sees this header, it will look like HTTP_FRONT_END_HTTPS. Note also that Netscaler doesn’t send this header by default — you have to configure it to add the header. This is documented here, and there’s a nice video demo of how to do it here.

    In the end, because we’re doing our entire site with HTTPS only, I elected to use the wordpress-https plugin, which does a good job of handling edge cases (like other wordpress plugins that have hard coded http:// URLs that will cause warnings on your secure pages). I patched the plugin to recognize the HTTP_FRONT_END_HTTPS header and am submitting a patch to the author, so at some point this should be support by that plugin.

    Good luck!

  2. I solved this issue for me, by going into the site’s CDN (Cloudflare) and setting the SSL mode to ‘full’

    Previously it was on ‘flexible’ which I suppose was causing or allowing the mix of http and https requests.

    Even though I had the CDN on ‘developer’ mode (which I thought stopped the CDN from affecting the site), while I was troubleshooting this issue, the SSL setting still had an affect.