curl-library
Re: hostname matching failure with multiple SAN DNS names
From: John T Kohl <jtk_at_us.ibm.com>
Date: Tue, 15 Dec 2015 08:18:36 -0500
Yes, Roy's proposed change works fine for me.
--
John Kohl
Senior Software Engineer
IBM Systems, Middleware
Littleton, Massachusetts, USA
jtk@us.ibm.com
From: Ray Satiro via curl-library <curl-library@cool.haxx.se>
To: curl-library@cool.haxx.se
Date: 12/14/2015 17:01
Subject: Re: hostname matching failure with multiple SAN DNS names
Sent by: "curl-library" <curl-library-bounces@cool.haxx.se>
On 12/14/2015 10:48 AM, John T Kohl wrote:
I have a certificate with two subject alternative names (DNS names).
Using a variant of curl that calls x509asn1.c:Curl_verifyhost() (such as one built using GSKit), the certificate validation fails because the code is returning early in the case where the first alternative name is not a match:
/* Check all GeneralNames. */
for(q = elem.beg; matched != 1 && q < elem.end;) {
q = Curl_getASN1Element(&name, q, elem.end);
switch (name.tag) {
case 2: /* DNS name. */
i = 0;
len = utf8asn1str(&dnsname, CURL_ASN1_IA5_STRING,
name.beg, name.end);
if(len > 0)
if(strlen(dnsname) == (size_t) len)
i = Curl_cert_hostcheck((const char *) dnsname, conn->host.name);
free(dnsname);
if(!i)
return CURLE_PEER_FAILED_VERIFICATION;
matched = i;
break;
It looks to me like this return statement is incorrect--the loop should be continued and additional SANs should be considered. If none of them match, then the code falls through to the case of failing (matched == 0) and rejects the hostname verification.
It looks that way to me too. Only GSKit is affected. I don't use GSKit but I was able to confirm by modifying openssl.c to use Curl_verifyhost. Please test the proposed fix at https://github.com/bagder/curl/compare/curl-7_46_0...jay:fix_gskit_verifyhost_altnames?expand=1
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Date: Tue, 15 Dec 2015 08:18:36 -0500
Yes, Roy's proposed change works fine for me.
--
John Kohl
Senior Software Engineer
IBM Systems, Middleware
Littleton, Massachusetts, USA
jtk@us.ibm.com
From: Ray Satiro via curl-library <curl-library@cool.haxx.se>
To: curl-library@cool.haxx.se
Date: 12/14/2015 17:01
Subject: Re: hostname matching failure with multiple SAN DNS names
Sent by: "curl-library" <curl-library-bounces@cool.haxx.se>
On 12/14/2015 10:48 AM, John T Kohl wrote:
I have a certificate with two subject alternative names (DNS names).
Using a variant of curl that calls x509asn1.c:Curl_verifyhost() (such as one built using GSKit), the certificate validation fails because the code is returning early in the case where the first alternative name is not a match:
/* Check all GeneralNames. */
for(q = elem.beg; matched != 1 && q < elem.end;) {
q = Curl_getASN1Element(&name, q, elem.end);
switch (name.tag) {
case 2: /* DNS name. */
i = 0;
len = utf8asn1str(&dnsname, CURL_ASN1_IA5_STRING,
name.beg, name.end);
if(len > 0)
if(strlen(dnsname) == (size_t) len)
i = Curl_cert_hostcheck((const char *) dnsname, conn->host.name);
free(dnsname);
if(!i)
return CURLE_PEER_FAILED_VERIFICATION;
matched = i;
break;
It looks to me like this return statement is incorrect--the loop should be continued and additional SANs should be considered. If none of them match, then the code falls through to the case of failing (matched == 0) and rejects the hostname verification.
It looks that way to me too. Only GSKit is affected. I don't use GSKit but I was able to confirm by modifying openssl.c to use Curl_verifyhost. Please test the proposed fix at https://github.com/bagder/curl/compare/curl-7_46_0...jay:fix_gskit_verifyhost_altnames?expand=1
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-12-15