Enabling FORCE_SSL_ADMIN breaks wp-cron.php

[dphiffer]

I just completed a server migration and discovered that scheduled posting broke during the process. I tried a few things, including the suggestions from ticket #8923 with no luck. I realized that one change I made, on the new server, was a requirement that the admin uses SSL. After disabling FORCE_SSL_ADMIN I discovered that scheduled posts work again. It seems that I can leave FORCE_SSL_LOGIN turned on and it doesn't cause any problems. This is good enough for our security needs, but I'm sure others might want to have both enabled.

Relevant code:

wp_remote_post( $cron_url, array('timeout' => 0.01, 'blocking' => false, 'sslverify' => apply_filters('https_local_ssl_verify', true)) );

If you're using a self-signed or invalid cert, then sslverify=true will prevent the request. You can try this:

add_filter( 'https_local_ssl_verify', '__return_false' ); // __return_false() is 3.0

IMO, the security check should be relaxed there for cron, It should allow a loopback connection without having to verify the certificate is correct, its not like a man in the middle attack could occur here?

Use wp_remote_head instead of wp_remote_post with empty body and switch default for sslverify to false

So nacin, Viper007Bond and myself discussed that we should switch sslverify to false as a default and keep the filter so if it is needed we can force verification.

Also we were using wp_remote_post with no body, which gets converted to a GET request and we make sure in wp-cron.php that $_POST is empty before continuing.

We may still want to look at the following logic in wp-cron.php as it seems a little strange that we are making sure $_POST is empty:

if ( !empty($_POST) || defined('DOING_AJAX') || defined('DOING_CRON') )
        die();

Per dd32 there are problems with some hosts where head requests are not processed properly. Just relax the ssl verification for cron requests.

There is currently a filter in place that can fix this, this isn't a regression. Let's get this right in 3.1.

Still needs feedback on proper course here.