hm,
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 PMTo: [EMAIL PROTECTED]Subject: RE:
Reverse Proxy SSLWhat
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. SylvainSylvain
MaretSenior Security Engineere-Xpert Solutions SARoute de
Pré-Marais 291233 Bernex / GenevaSwitzerlandTel: +41 22 727 05
55Fax: +41 22 727 05 50Mail: [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
SSLUnfortunately, 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 PreeceSent: Wednesday, July 11, 2001 9:22
PMTo: [EMAIL PROTECTED]Subject: Reverse Proxy
SSLOK, 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
---DISCLAIMERThis
email and any files transmitted with it, including repliesand forwarded
copies (which may contain alterations) subsequently transmitted from the
Company, are confidentialand solely for the use of the intended recipient.
It may containmaterial protected by attorney-client privilege. The
contents do not represent the opinion of e-Xpert Solutions SA exceptto
the extent that it relates to their official business.If you are not
the intended recipient or the person responsiblefor delivering to t
