On 07-06-13 16:09, Aleksey Tulinov wrote: > I've noticed that cURL changed behavior in 7.29 regarding axTLS > support. Before it was ignoring invalid certificates as requested, but > in 7.29 it gives "subjectAltName(s) do not match %s" error and ignores > curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L);
FWIW: The commit was introduced in the 7.28-1 release. > I've traced it to this commit: > https://github.com/bagder/curl/commit/1394cad30fcac7eb21adb9158dfcfab10e9f53d4 > and it says "honoring > the VERIFYHOST setting" but apparently it's not. Well... it was meant to relate to the part "setting similar to the OpenSSL backend.". This was how curl handled the VERIFYHOST setting with an OpenSSL backend. axTLS was the first of a few SSL backends that needed fixing and decided to mimic the OpenSSL behavior. > RFC 2818 says > [...] > > I was under impression that VERIFYHOST == 0 should let host with > invalid certificate to pass checks, but this is only implemented > during Common Name (if present) check. Patch that fixes this is listed > below. I concur with the patch. It matches the intend of the VERIFYHOST option and, if I'm not mistaken, this is how curl with an OpenSSL backend behaves these days. > Any ideas? Also note that not all SSL backends are able to make use of the VERIFYHOST setting: List as per release 7.28-0 http://curl.haxx.se/mail/lib-2012-10/0244.html Some SSL libraries can only switch (hostname) verification on or off. Oscar
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
