Age | Commit message (Collapse) | Author |
|
|
|
client certificates! (http://curl.haxx.se/bug/view.cgi?id=1348930).
|
|
#1334338 (http://curl.haxx.se/bug/view.cgi?id=1334338). When reading an SSL
stream from a server and the server requests a "rehandshake", the current
code simply returns this as an error. I have no good way to test this, but
I've added a crude attempt of dealing with this situation slightly better -
it makes a blocking handshake if this happens. Done like this because fixing
this the "proper" way (that would handshake asynchronously) will require
quite some work and I really need a good way to test this to do such a
change.
|
|
previously failed due to GnuTLS not allowing x509 v1 CA certs by default.
|
|
|
|
|
|
|
|
Archived thread of the help-gnutls mailing list regarding this problem:
http://lists.gnu.org/archive/html/help-gnutls/2005-04/msg00000.html
(and I _am_ sorry for my confused behaviour on this problem.)
|
|
bug I thought I saw before when I changed this...!
|
|
(missing file, bad file, etc), gnutls will no longer handshake properly but it
just loops forever. Therefore, we must return error if we get an error when
setting the CA cert file name. This is not the same behaviour as with OpenSSL.
Question/report posted to the help-gnutls mailing list, April 8 2005.
|
|
internally, with code provided by sslgen.c. All SSL-layer-specific code is
then written in ssluse.c (for OpenSSL) and gtls.c (for GnuTLS).
As far as possible, internals should not need to know what SSL layer that is
in use. Building with GnuTLS currently makes two test cases fail.
TODO.gnutls contains a few known outstanding issues for the GnuTLS support.
GnuTLS support is enabled with configure --with-gnutls
|