Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Message-Id: <CC7ECDC0-1E82-4E20-8D79-CFB34E34DE19@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: dev@httpd.apache.org
In-Reply-To: <4EB9C0BA.4@primary.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Small things to do
Date: Wed, 9 Nov 2011 12:02:46 +0200
References: <alpine.DEB.2.00.1111082150000.8155@eru.sfritsch.de>
 <4EB9B531.4060708@primary.net>
 <822ECDF5-0ED6-4F84-9847-7DD56C5853B2@sharp.fm> <4EB9C0BA.4@primary.net>

On 09 Nov 2011, at 1:52 AM, Daniel Ruggeri wrote:

>   One thing I know for certain that does not fall in line with this is
> if some.where.back.there and some.where.different are signed out of  
> the
> same CA, but you wish to send different client certs based on path  
> (such
> a use case exists, silly as it may seem in my eyes).

That would be the use case, yes.

We have a service oriented platform that is hardened end to end, in  
other words services are client cert protected, and apps must strongly  
authenticate to use the service using their own client cert. Sometimes  
the apps need to expose the URL space of the service directly (for the  
benefit of ajax, etc), but currently can't using a simple proxypass  
because the app next door needs to expose a different service with a  
different client cert.

As to the use case being silly, we live in an age of the cloud, where  
one app at location A is referencing a service in location B, with an  
unsecured network in between. Times have changed :)

Regards,
Graham
--