> Functionality wise, axTLS doesn't like my ca cert bundle so whatever
> site I
> try I can't get axTLS to play with me. See below, but the exact site
> doesn't
> seem to matter:
>
> $ ./src/curl https://www.sf.net/ -1 -v -k
> * About to connect() to www.sf.net port 443 (#0)
> * Trying 216.34.181.60... connected
> * Connected to www.sf.net (216.34.181.60) port 443 (#0)
> Error: Invalid X509 ASN.1 file
> * error reading ca cert file /etc/ssl/certs/ca-certificates.crt
> * Curl_axtls_close
> Error: No trusted cert is available
> * Closing connection #0
> * Curl_axtls_close
> * Curl_axtls_close
> * Curl_axtls_close
> * SSL peer certificate or SSH remote key was not OK
> curl: (51) SSL peer certificate or SSH remote key was not OK
> * Curl_axtls_close_all
>
> (The ca cert is the one Debian unstable ships and it should be fine as
> it
> works with OpenSSL and GnuTLS etc.)
>

I found two very annoying traits of axTLS cert handling that don't matter for our application, but will probably impact everyone else.

First, axTLS doesn't handle odd key sizes. According to their bug tracker (http://sourceforge.net/tracker/?func=detail&aid=3078372&group_id=171217&atid=857113), it appears that only key lengths that are multiples of 16 work correctly. I had to switch out the default stunnel.pem key that is in the cURL source (it uses a 1234-bit key) to get the tests to work.

Second, axTLS only sees a key as being in non-binary format (ie, PEM) if "-----BEGIN" are the opening 10 bytes of the file. This has been posted as a bug to their list (http://sourceforge.net/tracker/?func=detail&aid=3123838&group_id=171217&atid=857113), but has not received any comment. Moving any of the "-----BEGIN" blocks in a cert bundle to the beginning of the file should work.

If neither of those two things help, then you've uncovered something new.

Eric
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-12-13