Subject: mod_ssl, Apache 2.0.35 and ProxyPass

From: Guan Yang <[email-masked]>
Date: Sat, 27 Apr 2002 13:15:15 +0200

I am using Apache 2.0.35 (configured using --enable-ssl 
--enable-proxy) and I am having some problems with using ProxyPass 
over an SSL-encrypted server.

For example, here are the relevant lines from ssl.conf:

<VirtualHost _default_:443>

#  General setup for the virtual host
DocumentRoot "/var/apache2/htdocs"
ProxyPass /hello http://unicast.org/
ServerName npcomplete.unicast.org:443
ServerAdmin [email-masked]
.
.
.

(nothing else has been changed)

https://unicast.org/ works fine (you can test it), but when I try to 
access https://unicast.org/hello/ it doesn't work. The browser simply 
times out.

Can anyone help me?

______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Mads Toftum <[email-masked]>
Date: Sat, 27 Apr 2002 13:53:47 +0200

> over an SSL-encrypted server.
ProxyPass is broken for ssl vhosts in Apache 2.0.35 - either use
the latest cvs version (where this bug has been fixed) or wait 
for the next Apache2 release.

vh

Mads Toftum
-- 
With a rubber duck, one's never alone.
              -- "The Hitchhiker's Guide to the Galaxy"
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Patrick Herborn <[email-masked]>
Date: Mon, 29 Apr 2002 11:43:01 +0100

On Sat, 27 Apr 2002 13:53:47 +0200

> for the next Apache2 release.

It has been broken for a while, I posted the problem on the list a while back,
but at the time noone had a solution. If you inspect the ssl engine logfiles
you'll see that it is treating the back end server as an SSL client, which is
incorrect. Guess I'll have to give the CVS version a try... having to use
Apache 2 *AND* Apache 1.3 on the same box to deal with http and https is
annoying.

Cheers,

Pat.

---

From: [email-masked] (Johannes Artur Bertscheit)
Date: Thu, 02 May 2002 14:01:36 +0200

Hi all,

I still look for a working Apache 2.0.x with the following properties:
- for Windows (NT or 2000)
- pre-compiled binary or compilable with VC++ 6.0
- mod_ssl enabled
- the right openssl inclulded
- working SSL-ProxyPass (https >> http mapping to map internet SSL to 
intranet non-SSL servers)
(in  reading the mod_ssl mailing list - it seems that all of the above 
points are not working with 2.0.35)

Is it planned to test the next release 2.0.36 on windows / support it 
for windows including SSL-ProxyPass?

Has anyone experience with the Covalent Apache 2.0 (claiming to 
including SSL)(http://www.covalent.net)
Does it have the same bugs as the Apache 2.0.35 or works it for the 
above points?

Thanks in advance.

Johannes

---

From: Cliff Woolley <[email-masked]>
Date: Thu, 2 May 2002 15:28:25 -0400 (EDT)

> for windows including SSL-ProxyPass?

Current release schedule has 2.0.36 coming out on Monday.  Win32 binaries
will be provided and are well-supported.  BUT: official binaries from
apache.org don't include mod_ssl due to ongoing questions of export
restrictions.  You can compile it yourself with VC6.  ProxyPass
https->http has been fixed.

--Cliff

---

From: "Dwayne Miller" <[email-masked]>
Date: Thu, 02 May 2002 15:47:05 -0400

First I've seen of the SSL issues still remaining.  I thought 2.0 WOULD 
have SSL because the SSL restrictions went away.  Can you point me to a 
location where I can catch up on the ongoing discussions/questions?

Not that I have a problem compiling it... just curious.

Thanks.

---

From: Cliff Woolley <[email-masked]>
Date: Thu, 2 May 2002 15:49:52 -0400 (EDT)

> Not that I have a problem compiling it... just curious.

I honestly haven't followed it that closely.  It's something along the
lines of it's clear that we can distribute _source_ for strong encryption
software from within the US, but it's not clear that we can distribute
_binaries_ of strong encryption software.  I personally think that's
ridiculous, but some of the developers involved with creating the binary
distributions just felt that this was the safer path until the government
makes it clearer to us what's allowed and what's not.  Search the archives
for [email-masked], it's in there somewhere.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   [email-masked]
   Charlottesville, VA