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
