hmmmmm,
Thanks
Sylvain, but the perl scripts on my internal web server check cert details like
issuer, common_name and expiry date before continuing. This is just
additional security for permission to continue ie: If common name is in a
db and issuer is myCA then continue - else - Nasty Msg. I would have to run
these perl scripts on the external server for this to work. I am not comfortable
with that idea.
Therefore, I still need the following ;
https
client-------->Tunnel reverse proxy server----------->https internal
server with client Auth (X.509).
Besides the users like it when the page presents prefilled web forms with
details from their certificate mapped to a user
db :-)
You
see, I have been running this system internally for quite some time, but now I
need to open it up to some external users. The simplest secure way would be to
reverse proxy SSL transparently. Is there really no-one else who needs to do
this?
Feeling like the odd one out again,
Roy
Preece
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED]
Sent: Friday, July 13, 2001 10:14 PM
To: [EMAIL PROTECTED]
Subject: RE: Reverse Proxy SSL
What you can do is:
https ---------> reverse proxy SSL with Client authentication (X509) -------------------------------->https to your internal web server (192.168.x.y) as exemple
In this case you authenticate on the reverse proxy with your personal cert and the reverse proxy get the internal content with https (SSL)
proxypass / https://172.20.1.10:444/
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
SSLVerifyClient require
SSLVerifyDepth 10
It work on my side.
Sylvain
--------------------------------------------------------------------------------------------------------
Sylvain Maret
Senior Security Engineer
e-Xpert Solutions SA
Route de Pr�-Marais 29
1233 Bernex / Geneva
Switzerland
Tel: +41 22 727 05 55
Fax: +41 22 727 05 50
Mail: [EMAIL PROTECTED]
"Roy Preece" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]13.07.2001 14:02
Please respond to modssl-users
To: <[EMAIL PROTECTED]>
cc:
Subject: RE: Reverse Proxy SSL
Unfortunately, it seems that the answer is.....................................
#1. Nobody seems to have successfully reverse proxied to a https server on a private (192.168) network
https-------->Straight thru proxy---------->https cert authentication + (perl $ENV{'SSL_CLIENT_S_DN_CN'} stuff.)
I will look at implementing the following less secure method.
https-------->Authenticating Proxy + (perl $ENV{'SSL_CLIENT_S_DN_CN'} stuff.)---------->Plain old http + NFS.
OR
VPN
Cheers,
Roy Preece
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Roy Preece
Sent: Wednesday, July 11, 2001 9:22 PM
To: [EMAIL PROTECTED]
Subject: Reverse Proxy SSL
OK, from the lack of response to my previous email (SSLClient Browser <--> Apache Proxypassreverse <--> https://192.168.xxx.xxx) I can deduce one of two cases is true.
1. Nobody has successfully achieved a reverse proxy of SSL in the way I am describing, (Hard to believe)
or...........
2. You are really sick of this question.(Sorry)
If you chose 2, I have read through all of the mail archives on this list and others with regard to reverse proxying https. The most popular config seems to be to run SSL between the browser and the proxy server and then plain old http between the proxy server and the backend private servers. However, I want the client browser to use a cert to authenticate directly on the back end server on a private network, therefore I just want the reverse proxy to pass the encrypted traffic back and forth.
Is this possible..................How? Tips and pointers greatly appreciated.
TIA,
Roy Preece
-----------------------------------------------------------------------------------------------
DISCLAIMER
This email and any files transmitted with it, including replies
and forwarded copies (which may contain alterations)
subsequently transmitted from the Company, are confidential
and solely for the use of the intended recipient. It may contain
material protected by attorney-client privilege. The contents
do not represent the opinion of e-Xpert Solutions SA except
to the extent that it relates to their official business.
If you are not the intended recipient or the person responsible
for delivering to the intended recipient, be advised that you
have received this email in error and that any use is strictly
prohibited. If you are not the intended recipient, please advise
the sender by return e-mail, then delete this message and any
attachments.
e-Xpert Solutions SA: [EMAIL PROTECTED]
