LiteSpeed Support Forums - LiteSpeed load ballancer SSL problems

LiteSpeed Support Forums (http://www.litespeedtech.com/support/forum/index.php)

- General (http://www.litespeedtech.com/support/forum/forumdisplay.php?f=29)

- - LiteSpeed load ballancer SSL problems (http://www.litespeedtech.com/support/forum/showthread.php?t=1412)

LiteSpeed load ballancer SSL problems

Good morning!

We are running (32 bit) LiteSpeed Load ballancer v 1.0 on FreeBSD 6.2-RELEASE (with OpenSSL 0.9.7e).

So far, I have taken the following steps:
1) created a self-signed server certificate & private key,
2) created a listener on port 443
3) set <Listener>General>Secure to Yes
4) set <Listener>SSL PrivateKey & Server cert. file locations to correct values
5) set <Listener>SSL>Chained Certificate to NO
6) enabled all SSL protocol versions and encryption levers apart from eNULL

After clicking "Apply changes & restart", the server process dies without any errors in the error log. It starts normally if I run the startup script under /usr/local/etc/rc.d, again without any errors in the error log.

The problem is the following - the load-ballancer IS accepting connections on port 443, but does not have SSL enabled on that port (plain HTTP requests on port 443 actually get relayed to the backend hosts).

All help will be deeply appreciated!

Kind regards,
Jurij Kovacic

This issue has been fixed in our 1.1 build a while ago, please try
http://www.litespeedtech.com/package...reebsd6.tar.gz

SSL works on 1.1

Thank you for the advice - SSL works as expected in LSLB ver. 1.1 :)

I am now trying to proxy WebDAV requests to the backend server. It seems there is a problem with WebDAV's MOVE request - is LSLB compatible with WebDAV?

Kind regards,
Jurij Kovacic

MOVE request should be supported, can you give a sample MOVE Request with all the request headers?

What kind of backend is used HTTP proxy or AJPv13?

Problem with WebDAV protocol on Apache running HTTP through SSL hardware or proxy

Hello again!

The problem turned out to be not with proxy server, but with WebDAV protocol implementation and is sprecific to Apache server running HTTP, fronted by (any) proxy server doing SSL offloading.

A similar problem report is also avaliable here:
http://svn.haxx.se/users/archive-2006-03/0549.shtml

The following description is for the benefit of others, who will stumble upon the same problem in the future.

WebDAV client sent the following request:

MOVE /DAV/web-root/files HTTP/1.1\r\n
Accept-Language: en-us;q=0.5\r\n
Overwrite: F\r\n
Destination: https://www.mydomain.com/DAV/web-root/filesfg\r\n
Translate: f\r\n
User-Agent: Microsoft Data Access Internet Publishing Provider DAV 1.1\r\n
Host: www.mydomain.com\r\n
Content-Length: 0
Connection: Keep-Alive\r\n
X-Forwarded-Proto: https\r\n
Accept-Encoding: gzip\r\n
X-Forwarded-For: 10.18.18.13\r\n

The server responded with:

HTTP/1.1 502 Bad Gateway\r\n
Date: Thu, 18 Oct 2007 07:57:14 GMT\r\n
Server: Apache/2.2.4 (FreeBSD) DAV/2 mod_fastcgi/2.4.2\r\n
Content-Length: 253
Keep-Alive: timeout=5, max=99\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html\r\n
\r\n

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>502 Bad Gateway</title>
</head><body>
<h1>Bad Gateway</h1>
<p>Destination URI refers to different scheme or port (https://hostname:443)
(want: http://hostname:80)</p>
</body></html>

---------------------------------

The reason for this lies in httpd-2.0/modules/dav/main/mod_dav.c source code:

...
if (strcasecmp(comp.scheme, scheme) != 0 ||
comp.port != port) {
result.err.status = HTTP_BAD_GATEWAY;
result.err.desc = apr_psprintf(r->pool,
"Destination URI refers to different "
"scheme or port (%s://hostname:%d)"
APR_EOL_STR "(want: %s://hostname:%d)",
comp.scheme ? comp.scheme : scheme,
comp.port ? comp.port : port,
scheme, port);
...

The workaround is simple enough - the Destination request header needs to be rewritten before mod_dav starts processing the request - either by proxy server or Apache server itself. I chose the latter option as described here:
http://httpd.apache.org/docs/2.2/mod...ers.html#early

Basically, what needed to be done was to add the following directive to WebDAV's virtual host config:

..
RequestHeader edit Destination ^https: http: early
..

Thank you for your help!

Regards,
Jurij Kovacic

Thanks for the work around, it should benefit others who come across the same problem.