cURL / Mailing Lists / curl-library / Single Mail


Re: ssl options question

From: Tiberiu Motoc <>
Date: Fri, 3 Apr 2009 09:25:50 -0700

Great. Thanks so much for taking the time to explain these things to me.

I really appreciate it.


On Thu, Apr 2, 2009 at 11:41 PM, Michael Wood <> wrote:
> On Thu, Apr 2, 2009 at 11:34 PM, Tiberiu Motoc <> wrote:
>> On Thu, Apr 2, 2009 at 7:22 AM, Michael Wood <> wrote:
>>> On Thu, Apr 2, 2009 at 2:59 PM, Daniel Stenberg <> wrote:
>>>> On Wed, 1 Apr 2009, Tiberiu Motoc wrote:
>>> [...]
>>>>> Is there a browser (let's say Firefox) equivalent action for setting up
>>> Probably not. The browser probably only accepts one format for its
>>> certificates.
>>> The CURLOPT_SSLCERTTYPE tells the SSL library what format the
>>> certificate file is stored in, e.g. "PEM", or "DER".
>>> See:
>> 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
> certificate.
> --
> Michael Wood <>
Received on 2009-04-03