Answers.Body: <p>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!</p>
  
  <p>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. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-04-19T22:03:03.040Z
Answers.LastActivityDate: 2017-04-19T22:08:35.230Z
Answers.LastEditDate: 2017-04-19T22:08:35.230Z
Answers.UserDisplayName: Eric H
Answers.Body: <p>The most likely causes for breakage with this change are:</p>
  
  <h2>Cron job is pointing to HTTP only</h2>
  
  <p><code>curl</code> by default will not follow 302 redirects, while <code>wget</code> will. If you're using curl, it won't work automatically when pointed to the non-SSL URL (not without <code>-L</code>, anyway). The 302 redirect can make this less obvious, since everything else that points to http "just works".</p>
  
  <p>(Your question says you've addressed that already, but I'm including this for others who face that issue.)</p>
  
  <h2>OS certificate chain does not recognise your new SSL cert</h2>
  
  <p>Another possibility is that <code>curl</code> or <code>wget</code> 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).</p>
  
  <h2>Debugging further</h2>
  
  <p>I would:</p>
  
  <ul>
  <li>Check if your OS has updates available to certificate authority certs (in Debian distros, package is <code>ca-certificates</code>).</li>
  <li>Include in this question the output of the cron task you have configured.</li>
  <li>Review (and include in this question) the webserver access logs for your cron task accessing CiviCRM. </li>
  <li>Review your site's SSL against a service like <a href="https://www.ssllabs.com/ssltest/" rel="nofollow noreferrer">Qualys SSLLabs</a> and verify that the SSL configuration is good. (You don't need a perfect score - but this may make some issues visible.)</li>
  </ul>
  
  <p>When doing so, make sure to anonymize the URL and sensitive data like API keys, as you've done in your initial <code>.htaccess</code> snippet.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-04-19T20:34:47.847Z
Answers.LastActivityDate: 2017-04-19T22:45:55.117Z
Answers.LastEditDate: 2017-04-19T22:45:55.117Z
Answers.UserDisplayName: Chris Burgess
Body: <p>TL;DR: Does anyone know why forcing https would break CiviCRM's cron jobs?</p>
  
  <hr>
  
  <p>A few days ago, I edited my .htaccess file to rewrite URLs to always use https, using the following code: </p>
  
  <pre><code>RewriteEngine On 
  RewriteCond %{HTTP_HOST} ^example\.com [NC]
  RewriteCond %{SERVER_PORT} 80 
  RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]
  </code></pre>
  
  <p>That change stopped CiviCRM from running its scheduled jobs (nothing being logged, emails not triggering, etc.). Running them manually still works.</p>
  
  <p>The day this problem came to light, I changed the corresponding cron job URL to https instead of http. No change. </p>
  
  <p>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.</p>
  
  <p>I'm running CivCRM 4.7.14 on Drupal 7.53.</p>
  
  <hr>
  
  <p>Edits prompted by answers:</p>
  
  <ul>
  <li>My OS is CentOS 6.9</li>
  <li>Certificate has a clean bill of health</li>
  <li>I configure my cronjobs via cPanel. The entry for this job, anonymized, is: </li>
  </ul>
  
  <p>GET '<a href="https://example.com/sites/all/modules/civicrm/bin/cron.php?name=actualname&amp;pass=actualpassword&amp;key=longhexidecimalkey" rel="nofollow noreferrer">https://example.com/sites/all/modules/civicrm/bin/cron.php?name=actualname&amp;pass=actualpassword&amp;key=longhexidecimalkey</a>'</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-19T20:51:24.560Z
Comments.Text: Identified a likely bug in that "Force Secure URLs" setting a few days ago, see [CRM-20448](https://issues.civicrm.org/jira/browse/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?
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-19T22:02:55.597Z
Comments.Text: @ChrisBurgess Tried this at your suggestion. No effect. Also tried disabling "Verify SSL Certs" with no effect.
Comments.UserDisplayName: Eric H
Tags: <cron-job><security><scheduled-job>
Title: Cron not working after forcing https
ThreadText: # Cron not working after forcing https
  
  (Asked by: username_0 on 2017-04-19)
  
  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>'
  
  **Tags:** cron-job, security, scheduled-job
  
  > **Comments:**
  > **username_1**: Identified a likely bug in that "Force Secure URLs" setting a few days ago, see [CRM-20448](https://issues.civicrm.org/jira/browse/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?  
  > **username_0**: @username_1 Tried this at your suggestion. No effect. Also tried disabling "Verify SSL Certs" with no effect.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2017-04-19. Score: 1 | Accepted answer
  
  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.
  
  
  ---
  
  ### Answer by username_1 on 2017-04-19. Score: 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](https://www.ssllabs.com/ssltest/) 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.
  
  
  ---
  
  