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.
>>
>>
>