Gotz,

Thank you taking the time to explain (is there a good online resource which
covers this stuff?)

So now it sounds to me as if I need

1) a series of certificates, issued by 'well-known' Certification
Authorities, which enable me to determine whether a received public key does
in fact belong to the entity to whom I wish to talk
2) A client certificate, in case the server asks me to identify myself

so:

1) who are the 'well-known' Certification Authorities, and how do I get their
certificates ?
2) how do I generate a client certificate

(are they downloadable from the browser, and useable once I convert the
format?)

thanks again,

Justin

Götz Babin-Ebell wrote:

> Hello Justin,
>
> Justin Worrall wrote:
> > I am trying to get curl to perform a connection to an https server. I am
> > well used to performing standard http get/post connections, but the
> > world of ssl, encryption, certificates etc is new to me.
>
> OK.
> To have a common ground:
>
> The base of the operation is public key cryptograpy.
> With public key cryptography you have 2 keys
> belonging to each other.
> The private key is kept by the owner
> and the public key is published to the world.
>
> When you encrypt something with the publik key,
> only somebody having the private key can decrypt it.
> And when you sign something with the private key,
> you can use the public key to verify that it was really
> signed with the private key.
>
> When you contact somebody, you normally don't want to
> contact only the owner of a private key,
> but a special entity (server or person).
>
> So you have to ensure somehow that the key pair
> of your peer belongs to the entity you want to talk to.
>
> Somebody you must trust must certify that the public
> key (and with that the key pair) belongs to a given name
> and you must verify that the given name belongs
> to the entity you want to talk to.
>
> This instance is called Certification Authority.
> And they issue so called certificates...
>
> > 1) It sounds as if each browser contains a "personal" certificate which
> > assists the server in authentication. If I want to access an https site
> > in the same manner as my browser, I need to
> >
> > - export the browser's certificate
> > - convert from PKCS#12 format to PEM format using OpenSSL
> > - use the PEM formatted certificate as a -E option with curl
> >
> > is this correct ?
>
> No.
>
> First of all each browser has a list of certificates
> for CAs the browser manufacturer accepted as trustworthy.
>
> Connecting a server that has a certifcate issued by one of these
> CAs should ensure you really contacted the host you wanted to contact.
> (simplified description)
>
> Additionally the server could ask you to identify youself.
> You do this by sending your personal certificate back to the server.
> This step is optional, only a few server require that.
>
> But you should have a list of CA certificates that you trust to issue
> server certificates.
>
> > 2) http://curl.haxx.se/docs/httpscripting.html suggests there are a
> > number of ways of doing https connections. In particular it suggests
> > that sometimes you might not need a certificate (ie just use 'curl
> > https:/www.xxx') at all. How does one determine whether one needs a
> > certificate to access a site or not ?
>
> If you are only interested in a encrypted connection,
> without really caring to whom you talk to,
> you can do SSL without server verification.
>
> The decission if you have to supply a client certificate
> is done by the server.
> So if the server requires you to give a client certificate,
> you have to supply one.
>
> Bye
>
> Boetz
>
> --
> Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
> Sonninstr. 24-28, 20097 Hamburg, Germany
> Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126

--
This is not an offer (or solicitation of an offer) to buy/sell the
securities/instruments mentioned or an official confirmation.  Morgan Stanley
may deal as principal in or own or act as market maker for
securities/instruments mentioned or may advise the issuers.  This may refer to
a research analyst/research report. Unless indicated, these views are the
author's and may differ from those of Morgan Stanley research or others in the
Firm. We do not represent this is accurate or complete and we may not update
this.  Past performance is not indicative of future returns. For additional
information, research reports and important disclosures, contact me or see
https://secure.ms.com.  You should not use email to request, authorize or
effect the purchase or sale of any security or instrument, to send transfer
instructions, or to effect any other transactions.  We cannot guarantee that
any such requests received via email will be processed in a timely manner.
This communication is solely for the addressee(s) and may contain confidential
information.  We do not waive confidentiality by mistransmission.  Contact me
if you do not wish to receive these communications.  In the UK, this
communication is directed in the UK to those persons who are market
counterparties or intermediate customers (as defined in the UK Financial
Services Authority's rules).
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php