On Mon, 23 May 2016, Erland Costyson wrote:

> In 7,47.1 "if if(check->type == target)" is false matched will still be -1 so

> .....
>
> will go to the last "else" and continue checking the certificate and I get a
> successful result.

Okey, I was only looking at the current code. But yes, if that is how it
worked then it was wrong for all I can see. If SANs are used in a cert, they
must match or the verification fails. Only if there's no SAN we should
continue and check the CN.

But:

A) real world certs don't use the GEN_IPADD field and certs are not issued to
IP addresses

B) it seems like a bug that would then mostly just fall through and then not
match the CN field other so in the end it equals out. It seems unlikely that
you have a list of SANs that don't match (using the other address kind) and
then a CN that matches.

> in 7.48 we will go to the CURLE_PEER_FAILED_VERIFICATION as it has an
> altname but not of the same type.

But didn't it before too, but in the CN checks below?

As you figured this out, I sort of get the sense that you have a case that
used to work that now reports error ?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html