2

TL;DR: Does anyone know why forcing https would break CiviCRM's cron jobs?


A few days ago, I edited my .htaccess file to rewrite URLs to always use https, using the following code:

RewriteEngine On 
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteCond %{SERVER_PORT} 80 
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

That change stopped CiviCRM from running its scheduled jobs (nothing being logged, emails not triggering, etc.). Running them manually still works.

The day this problem came to light, I changed the corresponding cron job URL to https instead of http. No change.

Subdomains with separate databases that don't force https are unaffected. "Force secure URLs" was on without incident before this problem started so I don't think that's a factor.

I'm running CivCRM 4.7.14 on Drupal 7.53.


Edits prompted by answers:

  • My OS is CentOS 6.9
  • Certificate has a clean bill of health
  • I configure my cronjobs via cPanel. The entry for this job, anonymized, is:

GET 'https://example.com/sites/all/modules/civicrm/bin/cron.php?name=actualname&pass=actualpassword&key=longhexidecimalkey'

2
  • Identified a likely bug in that "Force Secure URLs" setting a few days ago, see CRM-20448. It's unlikely that's your problem, but would you try disabling "Force SSL" (since your webserver now should do this) and see if that changes your cron results? Commented Apr 19, 2017 at 20:51
  • @ChrisBurgess Tried this at your suggestion. No effect. Also tried disabling "Verify SSL Certs" with no effect.
    – Eric H
    Commented Apr 19, 2017 at 22:02

2 Answers 2

3

The most likely causes for breakage with this change are:

Cron job is pointing to HTTP only

curl by default will not follow 302 redirects, while wget will. If you're using curl, it won't work automatically when pointed to the non-SSL URL (not without -L, anyway). The 302 redirect can make this less obvious, since everything else that points to http "just works".

(Your question says you've addressed that already, but I'm including this for others who face that issue.)

OS certificate chain does not recognise your new SSL cert

Another possibility is that curl or wget is rejecting the SSL certificate provided by your new URL. This can happen if the OS CA chain is outdated or misconfigured; it can also happen if your SSL installation is incomplete (and might not appear to be a problem if your browser includes CA components which your OS lacks).

Debugging further

I would:

  • Check if your OS has updates available to certificate authority certs (in Debian distros, package is ca-certificates).
  • Include in this question the output of the cron task you have configured.
  • Review (and include in this question) the webserver access logs for your cron task accessing CiviCRM.
  • Review your site's SSL against a service like Qualys SSLLabs and verify that the SSL configuration is good. (You don't need a perfect score - but this may make some issues visible.)

When doing so, make sure to anonymize the URL and sensitive data like API keys, as you've done in your initial .htaccess snippet.

1

Upon reading that cron output logs are emailed to root rather than logged on-server (in CentOS anyway), I found the answer in an email from the Cron Daemon in my spam folder. The message read "LWP will support https URLs if the LWP::Protocol::https module is installed." Bingo!

To install that module, I logged on to my WHM interface, went to "Install a Perl module", searched for "LWP::Protocol::https" and installed it. Cron completed successfully on the next run.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.