What makes a certificate invalid?

[Rupert Kittinger-Sereinig]

Ok, I see.

Maybe it is easiest to modify the source of the peer of the system under 
test to get the responses you expect?

Rupert


Shanishchara, Kunal schrieb:
> Thanks for your query Rupert.
> 
> The problem we are trying to solve is to test the behavior when a
> failure happens. Sorry for not making this clear in my earlier email. 
> 
> Regards,
> Kunal.
> 
>  
> 
> -----Original Message-----
> From: Rupert Kittinger-Sereinig [mailto:rks at mur.at] 
> Sent: Friday, December 11, 2009 3:58 PM
> To: Shanishchara, Kunal
> Subject: Re: What makes a certificate invalid?
> 
> 
> I do not understand the problem you want to solve. Why do you want the
> handshake to fail?
> 
> If you want to use this as a way for the client to choose between
> several certificates, I do not think this is necessary. The client
> certificate request already includes a list of Distinguished Names that
> are acceptable Certificate Authorities.
> 
> cheers,
> Rupert
> 
> 
> Shanishchara, Kunal schrieb:
>> Hi Daniel,
>>
>> Thank you for the detailed answers (previous email) and pointing to 
>> the link. These are very helpful.
>>
>> I must admit though that I am still unable to comprehend the right 
>> behavior for the particular scenario that I have in mind.
>>
>> I am going to describe it to the best of my ability. Please find the 
>> description below.
>>
>>
>>
>> Problem Description:
>>
>> I have generated my own root certificate, lets say xyz.cer. I use this
> 
>> root certificate to generate certificates for 2 different FQDNs, lets 
>> say abc.com and def.org.
>>
>> Now, I am trying to induce an authentication failure by doing the 
>> following.
>>
>> 1. The server sends the certificate generated for def.org and the 
>> client sends a certificate for abc.com. Both these certificates were 
>> generated using same X.509  certificate xyz.cer.
>> 2. The server expects the client to fail the TLS authentication during
> 
>> server hello, client hello messaging.
>> 3. Based on the authentication failure, client will fallback to 
>> def.org (as per the higher layer specification) and the successive 
>> attempt will go through.
>>
>>
>>
>> Questions:
>>
>> Is the Server correct in expecting an authentication failure in Step
> 2?
>> If no, apart from providing invalid certificate with some obvious 
>> cause (expired cert, etc..) is there another way to implement the 
>> functionality on the server?
>>
>> Thanks in advance. 
>>
>> Thanks and regards,
>> Kunal.
>>
>>
>>
> --
> Rupert Kittinger-Sereinig <rks at mur.at>
> Krenngasse 32
> A-8010 Graz
> Austria
> 
> 
> <DIV><FONT size="1">
> 
> E-mail confidentiality.
> --------------------------------
> This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. If you require assistance, please contact our IT department at helpdesk at spirent.com.
> 
> Spirent Communications plc,
> Northwood Park, Gatwick Road, Crawley,
> West Sussex, RH10 9XN, United Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
> 
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
> 
> Or if within the US,
> 
> Spirent Communications,
> 26750 Agoura Road, Calabasas, CA, 91302, USA.
> Tel No. 1-818-676- 2300 
> 
> </FONT></DIV>


-- 
Rupert Kittinger-Sereinig <rks at mur.at>
Krenngasse 32
A-8010 Graz
Austria