On Thu, Apr 2, 2009 at 11:34 PM, Tiberiu Motoc <tiberiu.motoc_at_gmail.com> wrote:
> On Thu, Apr 2, 2009 at 7:22 AM, Michael Wood <esiotrot_at_gmail.com> wrote:
>> On Thu, Apr 2, 2009 at 2:59 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>>> On Wed, 1 Apr 2009, Tiberiu Motoc wrote:
>>>> Is there a browser (let's say Firefox) equivalent action for setting up
>>>> CURLOPT_SSLCERTTYPE and CURLOPT_SSLKEYTYPE?
>> Probably not. The browser probably only accepts one format for its
>> The CURLOPT_SSLCERTTYPE tells the SSL library what format the
>> certificate file is stored in, e.g. "PEM", or "DER".
> Thanks. I should have asked my question on SSLCERT and SSLKEY, and why
> they should be used.
Normally (and in your case) only the web server has a certificate.
Normally you check the CA's cert against a local list of CAs to see if
it's valid, because it's easier to keep a small list of CAs than it is
to have a list of certificates for every web server you are likely to
talk to. In your case you only have a single URL that will never
change, so you don't need a CA. You may as well use a self-signed
certificate (unless arbitrary users are going to access the same URL
with a normal browser or something like that.)
That is the normal case, but the client can also present a certificate
to the server that the server checks to see if it knows the client.
This is what CURLOPT_SSLCERT and CURLOPT_SSLKEY are for. Browsers do
have equivalents for this. It's just that they are not often used. I
believe Firefox 3's equivalent is in Advanced -> Encryption -> View
Certificates -> Your Certificates -> Import.
As an aside, only the web server should have access to its key, so it
would not make sense for the client to specify anything related to the
server's key. Therefore CURLOPT_SSLKEY cannot have anything to do
with the server's key. i.e. it is for specifying the client's key.
In your other message you asked why you needed to check the
certificate. Well, if you don't check the certificate then someone
can set up a machine between you and the server (or they can convince
your client to connect to them instead of the server, e.g. with DNS
poisoning attacks, or arp spoofing) and then all they need to do is
give you their cert when you connect. You will think you are
connecting to the real server because you don't check if the cert is
the one you think it is. i.e. a "man in the middle" (MITM) attack.
To answer your question on what a peer certificate is: Since both the
client and the server can have SSL certificates (and since these could
both be peers instead of client and server, because they need not be
web client and web server but could be e.g. P2P clients) and each can
verify the other, "peer certificate" could just be used to mean "the
certificate that the other guy is using". So yes, it is an SSL
Michael Wood <esiotrot_at_gmail.com>
Received on 2009-04-03