On Mon, May 23, 2016 at 11:00 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

But:
>
> A) real world certs don't use the GEN_IPADD field and certs are not issued
> to IP addresses
>
>
I agree that a real world cert shouldn't use IP address but obviously I
have one. And that the customers integrator refuses to change from IP.

> 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.
>
>
Apparently I have that and at this time I'm not totally sure why it passes.

> 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 ?
>
>
Yes, it used to work. But did it work because the code didn't work as
intended or was a bug introduced in the change if RFC2818 should be follow
as the comment over the function suggests?

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-05-24