httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From allan juul <>
Subject Re: AW: [users@httpd] SSL termination on apache but clientcertificaterouted through
Date Thu, 15 Sep 2005 10:58:35 GMT
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 

>> 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 <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message