Support » Fixing WordPress » WordPress 4.0 in a SSL-loop

  • Dear fellow WordPress-users,

    WordPress 4.0 contains a new approach to https/ssl-installations: when the installation URL contains “https”, all pages of the installation are being forced into a https-connection.

    That is a great thing, actually. However: it doesn’t work if you use Cloudflare to port a https-connection, into a normal http-connection (Flexible SSL, see http://blog.cloudflare.com/static/images/ssl_options.png.scaled500.png). This is not a 100% secure connection, but it offers a bit more security than a plain http-connection.

    The problem is that WordPress 4.0 keeps redirecting the installation to the https-url, probably because the system somehow recognizes the visitor coming through a http-connection. This forces me to buy an expensive SSL-certificate and ask my host for extra IP addresses which, for all of my sites, will costs almost thousand dollars a year, which I don’t want to pay for.

    I tried to edit things in default-constants.php, which got altered in the 4.0 version, but this has not led to fixing the problem. Can someone please help me finding out how to end the loop so I can just continue using my installations through flexible ssl-connections? Thanks a lot!

Viewing 12 replies - 1 through 12 (of 12 total)
  • Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    This forces me to buy an expensive SSL-certificate and ask my host for extra IP addresses which, for all of my sites, will costs almost thousand dollars a year, which I don’t want to pay for.

    Can you provide an example URL of that? Also of you can walk us through what you’re seeing a little more by example then that would help too.

    Thread Starter DannyMe

    (@dannyme)

    Hi Jan,

    The problem is that if I want to show this to you, I actually have to put one of my websites in this loop — which makes it unreachable for visitors.

    Actually, there’s not much to see. https://dannymekic.com/ is being redirected to https://dannymekic.com/ because — apparently — the installation thinks that actually someone is visiting http://dannymekic.com/

    ——
    Chrome presents this error message:
    The webpage at https://dannymekic.com/ has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.
    Learn more about this problem.
    Error code: ERR_TOO_MANY_REDIRECTS
    ——

    When I change my WordPress URL back to http://… the redirect-loop stops.

    Here I found some changes on the way WordPress handles https-installations, but until now I was not able to find the piece of code that puts the installation in this loop:

    https://core.trac.wordpress.org/ticket/27954
    https://core.trac.wordpress.org/changeset/28674
    https://core.trac.wordpress.org/ticket/28521

    Thanks for helping me out!

    Did you ever get a solution to this?

    We have the same issue with 4.0 but with our web hosting sat behind a load balancer/SSL accelerator.

    The way the set-up works is;
    https to the load balancer/accelerator on port 443
    http from the load balancer/accelerator to the port 81 on the web server

    3.9 was fine with this set-up, but 4.0 just doesn’t work and gets stuck in a redirection loop as it thinks access to it should be via https.

    We’ve had to remove the acceleration and forward the requests direct to the server. That means that we now incur additional costs due to the security certificates being installed on additional systems and also have a performance hit which isn’t great.

    Thread Starter DannyMe

    (@dannyme)

    Dear Davemacgb,

    Thank you very much for replying to my post: no, I didn’t find any solution yet, besides considering to buy SSL-certificates for all websites, which should not be the (expensive and unnecessary) solution because something inside the WordPress-code got changed and if we are able to find it, it can be simply undone. Unfortunately no one replied to my help request. Let’s team up, I am sure more people have the same problem.

    Jan Dembowski: any idea how we can find out which developers have been busy with the ssl-functionalities of WordPress 4.0, and bring this issue to their attention?

    D.

    Hi DannyMe, I work with Davemacgb – he works on our servers, firewalls, balancers, etc. and I carry out the website development. More than happy to work together to find a solution to this as it’s been incredibly painful for us.

    I can’t honestly believe that there isn’t more of an outcry over this as we’ve been forced to put in some huge (what we hope to be short term) changes to cater for this http / https issue for an update that WordPress themselves described as “just another number for us after 3.9 and before 4.1” and without any mention of this new “feature” at http://codex.wordpress.org/Version_4.0.

    It has so far cost us new certificates and a day and a half of downtime on a major website while we tried to figure out what the cause was. Your initial post was incredibly helpful in our diagnosis, actually, so thank you for that.

    Jan Dembowski:
    We also got the same infinite redirect shown in Google Chrome. What appeared to be happening was that the site believed, rightly, that it was in a non-ssl environment but it then chose to act on it and redirected to http://site.name (non SSL domain). We had an htaccess rule in place at that location to go back to https://site.name which then sent traffic back again and so the cycle continued. When we removed the http:// to https:// rule, the site loaded but all of the resources (stylesheets, JavaScript, etc.) were using http:// so didn’t load. This was despite the siteurl and home fields in the options table being set to https. We found ourselves having to hack the core code initially but it got to a point where it wasn’t a sustainable solution.

    It seems as though WordPress now makes that decision of whether to use http:// or https:// instead of leaving it up to us and what’s written into the required fields in the database / settings page as versions 3.9 and earlier did.

    Thread Starter DannyMe

    (@dannyme)

    hi Cooper,

    Shall we post a ticket in the Bugs-tracker of WordPress? Could you please prepare this? https://core.trac.wordpress.org/newticket

    Hi DannyMe – I’ve created a ticket at https://core.trac.wordpress.org/ticket/29708#ticket.

    Hope that’s okay?
    C.

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    Thanks for raising that trac ticket.

    Side note: @cooperman I have made your your other account @davemacgb inactive cause having multiple accounts in the same thread is considered E-V-I-L.

    Also I have a HUGE issue with anything that looks like sock puppetry. It’s a condition of mine. 😉

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    @davemacgb I’ve had more coffee and undone what I’ve done. Thanks for reaching out to me and explaining. 😉

    John Blackbourn

    (@johnbillion)

    WordPress Core Developer

    Hi folks,

    I’m the release lead for WordPress 4.1 and I’ve spent some time looking into this issue.

    First of all, I hope none of you who are using CloudFlare’s Flexible SSL are accepting
    card payments or submission of any other form of sensitive information on your website. The communication between CloudFlare and your web server happens in plain HTTP over the open internet. This is a breach of the trust of your visitors, and a violation of the principles of an HTTPS connection. Yes, it is “better than nothing” because it encrypts the communication between the client and CloudFlare, but it is far from ideal and should be used with caution.

    With that out of the way, on to the core issue:

    As DannyMe pointed out, WordPress 4.0 contains a small change which means a site which uses https as the scheme for its URL now enforces this scheme by way of a redirect. If a visitor accesses the site over http, they get redirected to the https version. I think we can all agree that this is a very good thing.

    An issue arises when a web server is sitting behind an HTTPS proxy but is itself accessed over HTTP (as is the case with CloudFlare’s Flexible SSL). If your website’s URL is set to an https URL then WordPress returns a redirect because the proxy server is requesting an http URL from your web server. The proxy server then requests the http version of the redirect, and you’ve got yourself an infinite loop.

    I’ve decided to revert the change which was made in 4.0 which causes this behaviour, in order to prevent more widespread issues now that CloudFlare is rolling out Flexible SSL en masse. The change will make its way into 4.0.1.

    In the interim, there’s no need to set up SSL on your web server to get around the issue. The fix – as has always been the case with an HTTP server behind an HTTPS proxy – is to instruct your server to respect the FORWARDED_PROTO HTTP header which is sent by the proxy server. Information can be found on the Codex, or you can use the newly released CloudFlare Flexible SSL plugin which uses a specific HTTP header sent by CloudFlare.

    For completeness sake, it should be noted that this isn’t a problem confined to WordPress. For example, Drupal requires an SSL module in order to support reverse SSL proxies, and Typo3 requires a CloudFlare extension if you’re using Flexible SSL.

    John

    Paul

    (@paultgoodchild)

    Just piping in here as the author of the CloudFlare Flexible SSL plugin (https://wordpress.org/plugins/cloudflare-flexible-ssl/), this isn’t a problem with WordPress, it’s a problem with how Flexible SSL works.

    Still, it’s not a problem with Flexible SSL either – simply an issue with the mechanics of using a proxy on 1 system (HTTPS) that accesses your web server on another (HTTP).

    – Use the Flexible SSL plugin to offset this problem.
    Don’t change your Site’s URL under General Settings
    – Use CloudFlare’s page rules to redirect to HTTPS.

    Use this tool to find assets that aren’t loading properly over HTTPS:
    https://www.whynopadlock.com/index.html

    More info & explanation: https://www.icontrolwp.com/2014/10/enabling-cloudflares-universal-flexible-ssl-wordpress-without-infinite-redirect-loops/

    Questions, drop me a message or comment on the post.
    Cheers,
    Paul.

    It’s not just CloudFlare. WordPress 4.0 put my site into redirect loops, and all I’m doing is a redirect of particular pages from https to http in .htaccess with WordPress and Site URLs set to https. Worked fine in 3.9.2.

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘WordPress 4.0 in a SSL-loop’ is closed to new replies.