LiteSpeed load ballancer SSL problems

Discussion in 'General' started by jurij, Oct 11, 2007.

  1. jurij

    jurij New Member

    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
  2. mistwang

    mistwang LiteSpeed Staff

  3. jurij

    jurij New Member

    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
  4. mistwang

    mistwang LiteSpeed Staff

    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?
  5. jurij

    jurij New Member

    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:

    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
    Translate: f\r\n
    User-Agent: Microsoft Data Access Internet Publishing Provider DAV 1.1\r\n
    Content-Length: 0
    Connection: Keep-Alive\r\n
    X-Forwarded-Proto: https\r\n
    Accept-Encoding: gzip\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

    <title>502 Bad Gateway</title>
    <h1>Bad Gateway</h1>
    <p>Destination URI refers to different scheme or port (https://hostname:443)
    (want: http://hostname:80)</p>


    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:

    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!

    Jurij Kovacic
  6. mistwang

    mistwang LiteSpeed Staff

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

Share This Page