Hi Alok;

On June 20, 2008 09:02:15 am AlokBhatnagar wrote:
> Thanks david,
>
> I know that the domain name should be same as the common name in server
> certificate which is sent by the server to the client.
>
> As I know, The SSL client verifies the server's certificate against the CA
> certificate loaded in the client.
>
> Suppose i trust Verisign CA. So my client must have Verisign CA Certificate
> in order to verify the server's certificate.
>

That is correct.

> So i want to ask, how will i get the CA certificate or list of CA
> certificates that i trust?
>
That depends on what your environment is - if you have fairly low security 
requirements, then just download the certificate from the Verisign web site. 
If you have more elaborate security requirements, then you need to talk to 
Verisign, and go through one of their protocols to validate that the Trust 
Anchor that you download or receive from them is really the one that you wish 
to trust, and that it is fully correct. 

Be very careful doing certificate validation - it isn't as straight forward 
as "is this cert signed by a CA that I trust" - there's also revocation 
checking, policy matching, and many other tests that *SHOULD* be performed, 
only some of which are provided by the OpenSSL verify functionality. For a 
full description of Path Validation and Discovery, take a look at RFC3280 (or 
5280 if you want to be REALLY up to date)

It all depends on your security requirements though - what is your risk 
profile? (Essentially - why are you even using SSL? Hide the data in transit? 
Are you worried about man in the middle attacks? Who is on your list of 
potential attackers? What is the value of the data that you are protecting?)

The answers to these questions will determine the level and complexity of 
checking you do - if all you are doing is trying to make casual evesdropping 
on the conversation between two IRC participants more difficult, then perhaps 
just checking the CA identity is enough... if you are concerned with 
protecting a multi-million dollar transaction, perhaps you should be being a 
bit more thorough :)

Have fun!

Patrick.


> Thanks
>
> Regards
> Alok Bhatnagar
>
>
> ----- Original Message -----
> From: "David Schwartz" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Friday, June 20, 2008 6:03 PM
> Subject: RE: Server Authentication
>
> > > So i want to know how will my client authenticate the server
> > > since i don't have the server's root certificate?
> > >
> > > Thanks in Advance..
> > >
> > > Regards
> > > Alok Bhatnagar
> >
> > That is completely application-dependent. The answer will depend on what
> > makes the legitimate server different from an imposter.
> >
> > Your question is basically, "how can I detect an impostor?". And the
>
> answer
>
> > is "as opposed to what?". For example, if the question is, "how can I
> > tell the real amazon.com from an impostor who doesn't control that
> > domain?" the answer is to see if the server presents a certificate with
> > 'amazon.com' in the common name that is signed by a CA you trust.
> >
> > If you don't know what CAs you trust, then you have a problem.
> >
> > DS
> >
> >
> > ______________________________________________________________________
> > OpenSSL Project                                 http://www.openssl.org
> > User Support Mailing List                    [email protected]
> > Automated List Manager                           [EMAIL PROTECTED]
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [email protected]
> Automated List Manager                           [EMAIL PROTECTED]



-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [email protected]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to