Re: [reSIProcate] TLS handshake failure
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.