SSL certificate issues

Re: SSL certificate issues

by Daniel Kaelin -
Number of replies: 13

I have found multiple fixes for this issue. We have our Moodle site sitting in a load balanced environment with SSL offloading. 

I was running into the same problem as you with HTTPS logins only and certain pages being rewritten as HTTPS which resulted in broken pages. 

 

Here are the fixes we have implemented in our environment to workaround these issues. I would test them with your environment prior to putting them on a production site. This is with Moodle 2.4.7 but I would imagine it applies to more than one version. 

 

1. Set sslproxy=true in config.php file 

2. Comment out the following section from /lib/setuplib.php.  Approximately line 822 - 828

3. Add the following lines to lib/pagelib.php typically found around line 1352

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {

                                    $_SERVER['HTTPS'] = 'On';

                                    return;

                        } else {

 

                                    redirect($this->_url);

                        }

 Use the image below as a guide. You will replace out the return; line with the enclosed code. 

4. To prevent form pages from being rewritten as HTTPS you will need to comment out the following lines around line 175 in /lib/formslib.php

            /*if (!empty($CFG->sslproxy)) {

                // return only https links when using SSL proxy

                $action = preg_replace('/^http:/', 'https:', $action, 1);

            }*/

 

 

In reply to Daniel Kaelin

Re: SSL certificate issues

by Susan Mangan -

Hi, we are using v.3.0 and your method of setting ssl=true and apply your code hacks did not seem to work for us.  Do you happen have updated code for version 3.0?  We are working on plan to move to all https but in meantime, looking for fix..... thanks in advance ....

In reply to Susan Mangan

Re: SSL certificate issues

by Just H -

No hacks required.

1 Change your wwwroot in config,php  to https  (e.g. $CFG->wwwroot   = 'https://yoursite.com';

2 Add/append to a .htaccess file in the Moodle root directory:

https:// redirect.

RewriteEngine On 

RewriteCond %{SERVER_PORT} 80 

RewriteRule ^(.*)$ https://www.yoursite.com/$1 [R,L]

In reply to Just H

Re: SSL certificate issues

by Susan Mangan -

Thanks ... but I want to redirect to http not https.

I've tried various versions of apache rewrite rules and cannot get it to work.

In reply to Susan Mangan

Re: SSL certificate issues

by Ken Task -
Picture of Particularly helpful Moodlers

Think you kinda piggy-backed on a conversation that sounded like your problem, but isn't - maybe.   Fist poster in this thread wanted https on certain pages in Moodle.    Discussion then moved to a load balanced setup where certain pages (internal) were http and then to hacks of code - which, as you say, aren't working for ya.   In your situation (depending on what that is) you may not need hacks.

So what is your setup ... load balanced?   Single RH Apache box in front with backended dedicated DB server?

Your site does load and display just  fine with http:// and with https:// for login only turned on it does flip to https:// just for the login with a valid cert ... and changes back to http:// (tested with guest login)

Google links to your site, however, present one with https:// which shows the wonky version.

Site does say y'all (pardon me, am in Texas, eh!) are going to be down/maintenance etc. coming up.

In RedHat apache config (httpd.conf) one could setup a redirect there (no htaccess but a true re-write rule forcing all traffic to https.   Right now, would think that needs to be done when the upgrade is made to the site ... since it's gonna be down for upgrade.

And, if switching everything to https ... you'll have to turn off the https for login only, change the URL in config.php AND run the search and replace tool for any internal links that are now in the DB of the site for http://yoursite/somestuff/image.png - as an example.

Not sure there is any recommended order in which to take the site from https on login only to https and upgrade but you might consider first flipping the entire site to https first.   Doing the search and replace ... checking things out to assure they work as expected under https.   Then do the upgrade.

Of course, I could have the whole thing wrong.    Mind explaining a little more ... or for others who might follow your path/issue, start a new discussion thread. ;)

'spirit of sharing', Ken

In reply to Ken Task

Re: SSL certificate issues

by Susan Mangan -

Thanks Ken.  I've been reading tons of articles and moodle posts on the issue I have been having ... and I thought this one was relevant however I could be wrong.  Our problem is simple, one that many others have as well. 

We will be putting into production very soon, a new load balanced setup using gluster and F5 with dedicated memcache server and DB server.  I will likely post our configuration in hardware forum for feedback - so far so good with testing though smile

However, for the interim I am just testing the rewrite in apache using a single web server (separate DB backend)  (Apache, MySQL)

We have a valid certificate.

We run our moodle over http using https for login only.

If a user types in https:// css breaks and some scripts don't run.  I know this is very common and the general consensus is to move to all https and do a database search and replace from http to https but I was just looking for a quick fix to keep everything http for the time being and try to redirect anyone who manually types in https to http.

Seems more difficult than I thought.  Followed some suggestions here http://stackoverflow.com/questions/8371/how-do-you-redirect-https-to-http

I might be missing something simple or I might be trying to fit a square peg into a round hole....

 

 

 

In reply to Susan Mangan

Re: SSL certificate issues

by Susan Mangan -

ahhhhh!!!  I got it finally.  I can now redirect https to http successfully but I get a loop error on login.  Sometimes I wonder if I should have spent this time simply configuring for all https!  lol

In reply to Susan Mangan

Re: SSL certificate issues

by Bret Miller -
Picture of Particularly helpful Moodlers

Yes, if you're going to force it to http using rewrite rules, you have to use RewriteCond to exclude the login URL's.

In reply to Susan Mangan

Re: SSL certificate issues

by Ken Task -
Picture of Particularly helpful Moodlers

Responding to this one ... but see your latest post says ya go it.

Two things:

"However, for the interim I am just testing the rewrite in apache using a single web server (separate DB backend)  (Apache, MySQL)"

AND

"valid Certificate"  (is that for this test setup?)   Would think it might be useful to have a certificate for the domain rather than for a specific server.   A domain cert is more expensive but whomever is the administrator for the certs can gen one up for any server that's going to be setup in the same domain.  Just a thought.    Would come in handy when setting up a test ... such as yours.

I do this often ... use same server or another physical server (has a different IP address) and configure the test setup with a virtual apache using the same FQDN as production.    I then use local machines host file to make an entry that associates the IP address of the test setup with the FQDN that will be used.   All machines handle DNS lookups the same way ... they check the local host file for references first before using actual DNS.    Only those that know the mapping of IP hostname and who can edit their host file are the only ones who will be accessing the 'stealth' setup.   Apache, if configured to serve out a virtual will do any domain ... even those that are NOT in any DNS.

Can develop all you like using the true FQDN of the production server ... remember all those internal URL's use wwwroot variable and are saved to DB.

The other ... longer way ... is to have two DB's for the 'stealth' box ... they match the wwwroot value as far as data then ... example: server non https uses nonDBname .... server configured to use https in config ... two changes ... the wwwroot + DB to the sslDBname.   The trick is to get both DB's with current info AND https or not which could be done via dump, sed edit, import into other.

This may/may not work for ya ... it's a thought, however. ;)

'spirit of sharing', Ken

In reply to Susan Mangan

Re: SSL certificate issues

by James McLean -

Is there a specific reason you don't want to run the whole site under HTTPS? When you run only login pages on HTTPS, but the rest of the site is on HTTP, this doesn't protect you from theft of cookies - meaning people can steal other peoples sessions on wifi (for example).

I would highly suggest keeping the whole site HTTPS at all times. There are no downsides and it is well supported.

In reply to James McLean

Re: SSL certificate issues

by Susan Mangan -

We are going to switch to https very soon I think, but first we need to configure https on our test server, run search and replace, and do some testing.  The last time I tested full https some of our scorm sites broke.

I was really just looking for a quick fix for the interim....

The apache rewrite seems to work fine on our regular test instance which is one web server but the same rule does not work on our load balanced F5.  Something in F5 config is now interfering.

In reply to James McLean

Re: SSL certificate issues

by Susan Mangan -

Hi James,

Question for you - how does caching in Moodle change when moving to all https?  We currently use memcache server for application cache.  We are using http with https over login only but considering a change to all https soon.  Do you happen to know how this might be affected by the change?

TIA!!!!

In reply to Susan Mangan

Re: SSL certificate issues

by James McLean -

Memcache, if used for Sessions or for MUC, communicates directly with Moodle itself. It's outside the SSL/TLS layer established by the webserver and the client - and thus works exactly the same weather SSL is enabled site-wide or not.