Apache - http requests redirected to https

Nothing in your httpd.conf is redirecting the clients - do you have a .htaccess file in //var/www/html/cisco (or /var/www/html) containing a RewriteRule?

I don´t see that file in the folders indicated, only this:

[root@elastix ~]# find / -iname "*.htaccess*"
/var/www/html/admin/modules/framework/htdocs/admin/modules/.htaccess
/var/www/html/admin/modules/.htaccess
/var/www/html/mail/logs/.htaccess
/var/www/html/mail/temp/.htaccess
/var/www/html/mail/config/.htaccess
/var/www/html/a2billing/api/.htaccess
/var/www/html/a2billing/lib/.htaccess
/var/www/html/a2customer/lib/.htaccess

[root@elastix ~]# find / -iname "*.htaccess*" | xargs grep -i rewrite

Was grepping for the word rewrite a good choice, or should I look for a different string?

Thanks for the help

No, that find/grep is perfect, and would've exposed it if it existed.  That is really strange, I practically would've bet money on it being a htaccess redirector.

Alright, please grep for "header" in any html/php files in the web root - specifically something like header("Location: https://xxxx"); where the xxxx part would be something like $_SERVER["HTTP_HOST"]/$_SERVER["$REQUEST_URI"]

grepping.....

meanwhile, do you know if it is possible/helpful to intensify the debugging to understand how this is happening?

I don't know of any way for Apache to get more granular in the logs than just reporting that the redirect occurred.

I gather it's probably in the actual site code if it's not in the server config or in the .htaccess files.  Just for grins though, you might peek in /etc/httpd/conf.d and make sure Elastix doesn't put any of its own files to be included in there that might have RewriteRule directives in them.

These are the files I can see in that directory:
[root@elastix conf.d]# ls
elastix.conf  php.conf        README    welcome.conf
mailman.conf  proxy_ajp.conf  ssl.conf
[root@elastix conf.d]#

None contains rewrite directives.... Any ideas ?  =(

You mentioned the code of the site, you mean like the PHP code?

Yes, the php code.  Did you find any header() directives when grepping?

No header() directives anywhere unfortunately.

I got this reply on another forum, I am barely digesting the indications though:

i never spoken about provisioning but just a Cisco phone wanting to connect to an URL for any thing.
For example, when a Cisco 7960 want to download a logo from an Elastix server, this function is impossible because apache switch to https.
So, in this case, you must enable the http or only on some folders to be connected on http and the others on https.

That turn around this into httpd.conf:
Order allow,deny
Allow from all
RewriteEngine off or on
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !(/xmlservices/*)
RewriteCond %{REQUEST_URI} !(/images/bmp/*)
RewriteRule (.*) %{HTTP_HOST}%{REQUEST_URI}

Don't forget to restart httpd.

# service httpd restart

I'm trying to understand it too.  The rule says to take non-SSL requests for anything except /xmlservices/ and /images/bmp/ and then just take them to their original destination.  That doesn't make sense to me, since I'm looking for where it takes all non-SSL requests to the SSL site so that it can be disabled.  Having warring rulesets doesn't sounds like my idea of a good time :)

I was trying to follow the instructions above, got some interesting results. Instead of a 302 redirecting to HTTPS, I get a 500 internal server error whit the following snippet right below the line "Order allow,deny" in httpd.conf:

        RewriteEngine on  --> I assume it must be turned on
        RewriteCond %{HTTP_USER_AGENT}  ^CIPC  --> this is the User-Agent value that appears in the captures
       RewriteRule (.*) %{HTTP_HOST}%{REQUEST_URI} --> this is what the other guy suggested

I am not to sure if the RewriteRule is correct, but for sure, is the snippet the one causing the 500 error, if I remove it then the 302 comes back.

Now, if I set up an Alias just like the one setup for the icons folder in httpd.conf, pointing to my cisco folder, then I can pull any file inside without being redirected. Not sure how that helps though...

xterm, do you know why if I only use the first two lines of the snippet in the general context the file is then served as I want to, and even looked up in the document root for the virtual host I configured instead of the DocumentRoot? As follows:

        RewriteEngine on  
        RewriteCond %{HTTP_USER_AGENT}  ^CIPC

Thanks a lot, I will answer your questions as soon as possible during work, or ultimately when I come back to my home lab, really appreciate the help.

When putting the RewriteRule, I am getting 13 of these lines in the dummy-host.example.com-error_log


Setting the LogLevel to debug catches this line several times:


The /dummy-host.example.com-access_log show this with the RewriteRule in the config file:


And something like this without the RewriteRule:


The files with error 404 are really not there, so its expected.

The code is not Cisco, only the HTTP client.

Grepping for https under /var returns lots of lines, some of which look suspicious of redirecting my traffic! Could you please tell me how a meta-refresh tag looks like? The output is attached, I can provide more details about any suspicious file elastix-putty.log

I think I found where it is redirecting, the file is /etc/httpd/conf.d/elastix.conf

Thank you for your help mate.

Great!  Out of curiosity, what was the line doing it in elastix.conf?

The file contains a snippet that causes  the redirection, I think we would´ve found it from the very beginning if the grep syntax were more flexible:

User asterisk
Group asterisk

<Directory "/var/www/html">
    # Redirect administration interface to https
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</Directory>

> I gather it's probably in the actual site code if it's not in the server config or in the .htaccess files.  Just for grins though, you might peek in /etc/httpd/conf.d and make sure Elastix doesn't put any of its own files to be included in there that might have RewriteRule directives in them.

I guess I could've told you to use grep -i, but I thought my capitalization above would demonstrate the case-sensitivity.  Oh well, we ran in a few circles but ultimately got to the right place - glad it's all fixed for you.