Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 55080 invoked from network); 15 Sep 2005 10:58:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 Sep 2005 10:58:42 -0000 Received: (qmail 24181 invoked by uid 500); 15 Sep 2005 10:58:30 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 24168 invoked by uid 500); 15 Sep 2005 10:58:30 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 24155 invoked by uid 99); 15 Sep 2005 10:58:30 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Sep 2005 03:58:30 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [200.46.204.129] (HELO muly.dk) (200.46.204.129) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Sep 2005 03:58:39 -0700 Received: from [10.202.94.33] (213.237.65.2.adsl.noe.worldonline.dk [213.237.65.2]) by muly.dk (Postfix) with ESMTP id 75D791E5D28E; Thu, 15 Sep 2005 10:58:24 +0000 (GMT) Message-ID: <432953DB.7000200@muly.dk> Date: Thu, 15 Sep 2005 12:58:35 +0200 From: allan juul User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Guenther, Christian" CC: users@httpd.apache.org References: <80794ACC-1EB4-4B1B-A9AE-69340EB50591@mimectl>,<43286315.7080408@muly.dk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: AW: [users@httpd] SSL termination on apache but clientcertificaterouted through X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Guenther, Christian wrote: > Hi Allan, > > thanks for your reply. > I'd like to take the chance and clarify two points, just to make sure. > > you said: > >> the backend *code* has a access to the client certificate. >> is it your backend *webserver* or is it your backend *code* that is >> handling the validation of the client certificate ? > > > The backend in this case is an application server to which a client > connects. > This application server is essentially SAP XI (an XML driven data > exchanger) > and the client is a so called Business Connector. It is actually the > client, the BC, that wants to pass some data about harvested stuff like > grain or so to the XI so that they get written into the SAP system. Bye > the way, the client is a PDA that sits on top of some tractor on some field > in the countryside. ok, all of this is way out of my league ;) but it still sounds as it is the actual application server that is handling the validation of a given client certificate (and not some of your custom made code). if that is the case i have no idea how you would let the client - the BC - pass the cert in a manner so the backend would be forced to validate it, sorry. > > The both components are talking to each other in a completely automated > manner - no user interaction at all. > The Application server requires some form of authentication for the client > to let it talk to him. Possible authentication systems are > username/password > wihich is not an option here due to corporate regulations, SAP Logon > Tickets, which apache does not understand and SSL certificates. > > The application server (XI) is a system with high security requirements and > can therefor not be placed in a normal DMZ but is needed to be secured by > the proxy. hmm ok, so it is actually strictly necessary to run ssl on apache (reverse proxy)? i gather you cannot bypass apache on https in your set up ? and since you run the backend with ssl you sort of have a "double" ssl connection in certain circumstances. would it be possible to this (i am asking the list too) ? client connects on ssl to apache with client certificate. apache forwards request to, say, a cgi program. program connects to backend via ssl and pass client certificate data on behalf of the original client. backend validates client certificate and send some kind of response. program picks up data from response and now sends an http redirect to the original client request. the redirected page will contain the backend response/data. i guess im thinking pretty traditional web environment, not tractor environment. >> what i don't understand at this point, is why you want the validating >> done at the backend at all, when you could have all this done at the >> frontend. > > > Because the XI requires authentication bevor it would let anyone talk to > it.. > And there are different frontends that have access to different data - > the application server needs to distinguish them. and it is not possible to have all the different frontend hit apache first i reckon, like: some client -> whatever frontend -> apache (reverse proxy) -> backend >> is it really nesecary to do the webserver validation on the backend. is >> it actually possible to bypass the apache frontend and therefore access >> the backend directly (which sounds slightly insecurish) >> (the solution i described, we had https at the frontend and http at the >> backend) > > > I fear it is at least necessary to give the XI access to the name of the > client connecting - in whatever way. The way the system is configured at > the moment it requires a client ssl certificate! > > Regards, > > Christia > n --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See for more info. To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org " from the digest: users-digest-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org