On 21/03/2011 22:38, plot.lost wrote:
> On 21/03/2011 21:49, Ben Noordhuis wrote:
>> Ah, it kind of depends. But if you can use PKCS12...
>>
>>> I've tried building a pkcs12 file that contains the client
>>> certificate and
>>> the relevant CA/Root certificates, and then converted that back into a
>>> single PEM file. That gets a PEM file that is different to the usual
>>> method
>>> of just sticking the certificates together - there are additional
>>> elements
>>> before each certificate (Bag Attributes, subject and issuer) but
>>> that is
>>> also rejected by the server.
>> ...then it's probably easiest to use that. Here is what you do:
>>
>> 1. Set CURLOPT_SSLCERT to the filename of the .p12
>> 2. Set CURLOPT_SSLCERTTYPE to the string "P12"
>>
>> That should be all, libcurl will set up the CA chain for you.
> Unfortunately that has not worked for me either, still getting the
> same error (error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert
> internal error) each time.
>
> I've tried using PEM and PKCS12 versions of the certificate file using
> 3 variations of each (1=Client, 2=Client+CA, 3=Client+CA+Root)
>
> I've tried disabling the verification of the server certificates
> (CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST) just to see if
> that made any difference, no luck with that either. Think I'm running
> out of SSL related options to try!
>
> Starting to think that I'm just not going to get this working...
>
>
Think I may of found something that could explain this:

-----------

    Usually servers send in the request to the client a list of
    Distinguished Names of certificates authorities (CA) they trust, so
    that the client can filter from the certificates available in the
    browser those that match. Getting client certificates signed by CA's
    is a complex and expensive procedure, which in part explains why
    requesting client certificates is very rarely used: very few people
    have certificates signed by well known CAs. Instead those services
    that rely on client certificate tend to sign those certificates
    themselves, becoming their own CA. This means that certificates end
    up being valid for only one domain. foaf+ssl bypasses this problem
    by accepting certificates signed by any CA, going so far as to allow
    even self signed certs. The server must therefore send an empty list
    of CAs meaning that the browser can send any certificate (TLS 1.1).

    http://lists.foaf-project.org/pipermail/foaf-protocols/2009-February/000264.html

------------

The server does appear to be sending an empty list of CA's, which is
causing libcurl (openssl?) to respond with no certificate instead of
sending the certificate I have passed in. This would appear to be
TLSv1.0 behaviour. Is there anything that can be done to use the TLSv1.1
behaviour of sending a client certificate even when the list of CAs is
empty?

//

/
/

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-03-22