< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] TLS handshake failure


I still don't understand - to use a different port (or different interface)
you will have to form a different TlsTransport and that can have a different
certificate.


On 6/7/05 2:48 PM, "Bob Bramwell" <bob@xxxxxxxxxx> wrote:

> Same port & same interface, no.  Same *transport* but different incoming and
> outgoing behaviour, yes.
> 
> Since a TlsConnection gets its Security object (and therefore its certificate)
> from the TlsTransport, and since Security (at present) can carry only one
> certificate, each TlsTransport requires ALL connections, regardless of
> direction, to use the same certificate.  Some of us want to make a distinction
> between client and server certificates using the same TlsTransport.
> 
> Cullen Jennings wrote:
>> There are cases where a single machine might have different certs, even for
>> the same DNS name, however, I've yet to see one of these where we are
>> talking about different certs for the same port on the same interface. If
>> someone knows of a use case like this, I'd love to hear about it.
>> 
>> Cullen
>> 
>> 
>> 
>> On 5/18/05 5:16 PM, "Bob Bramwell" <bob@xxxxxxxxxx> wrote:
>> 
>> 
>>> I haven't been following this discussion from the start, but it is ringing
>>> really loud bells for me.  Some time ago we had a rather similar discussion
>>> on
>>> this list in which the following snippet appeared:
>>> 
>>> 
>>>> Cullen Jennings wrote:
>>>> 
>>>> On 10/22/04 5:51 PM, "Bob Bramwell" <bob@xxxxxxxxxx> wrote:
>>>> 
>>>> 
>>>> 
>>>>> This note is part reality check and part change proposal.  Your
>>>>> constructive
>>>>> feedback will be most welcome.
>>>>> 
>>>>> I am trying to set things up to allow TLS connections to do client
>>>>> authentication.  There are a number of things, notably in the Security
>>>>> class,
>>>>> that will need to change to accomodate this.
>>>>> 
>>>>> At present a Security object has two public certificates associated with
>>>>> it:
>>>>> its publicCert and its publicIdentityCert.  The former is used as the
>>>>> certificate
>>>>> presented to a TLS client when it connects to a TlsConnection created in
>>>>> server mode.  The latter only appears to be used for signing stuff
>>>>> (computeIdentity
>>>>> and checkIdentity functions).  No provision is made for a client side
>>>>> certificate
>>>>> per se. 
>>>> 
>>>> 
>>>> uhmm the PublicCert would be used for this
>>> 
>>> I remain convinced that there *are* scenarios where distinct client and
>>> server
>>> certificates have to be presented.  IMO there ought to be provision for
>>> this.
>>> Presenting the server cert if no client cert were specified seems to be a
>>> reasonable default position to take.
>>> 
>>> Hope that helps,
>>> Bob.
>> 
>> 
>