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:address@hidden
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 <address@hidden>
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 address@hidden
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>