On Wed, 2019-10-16 at 01:08 +0200, Laszlo Ersek wrote:
> Notes:
>     Unfortunately, there are two problems with this patch:
>     
>     (1) X509_VERIFY_PARAM_set1_ip_asc() does not accept IPv4 addresses in
>         dot-decimal notation (unless I messed up the code). My log file
>         contains:
>     
>     > TlsDxe:TlsCertVerify: verifying peer certificate with DNS hostname "192.168.124.2"
>     > TlsDxe:TlsCertVerify: peer certificate accepted


That's odd; X509_VERIFY_PARAM_set1_ip_asc() shouldn't have failed on
that string.

I recommend staring very hard at the implementation of ipv4_from_asc()
in openssl/crypto/x509/v3_utl.c. Especially the 'scanf' part.

This one's going to bite you even when ditch my overly complex set of
callbacks and ex_data, and just use SSL_get0_param() sensibly.

>     (2) X509_VERIFY_PARAM_set1_ip_asc() does accept IPv6 addresses. However,
>         in that case, the server certificate that I had generated with
>         "genkey" (where I entered the IPv6 address in the Common Name field)
>         is rejected:
>     
>     > TlsDxe:TlsCertVerify: verifying peer certificate with numerical IP address "fd33:eb1b:9b36::2"
>     > TlsDxe:TlsCertVerify: peer certificate rejected
>     > TlsDoHandshake SSL_HANDSHAKE_ERROR State=0x4 SSL_ERROR_SSL
>     > TlsDoHandshake ERROR 0x1416F086=L14:F16F:R86
>     
>         If I do not apply the present patch on top of Jiaxin's v1 4/4 (at
>         <http://mid.mail-archive.com/20190927034441.3096-5-Jiaxin.wu@intel.com>),
>         then the certificate is accepted fine.

As I believe you have already concluded, this is correct behaviour.

That certificate is bogus, because your 'genkey' tool is not behaving
correctly (qv) and should have produced a cert with an iPAddress in its
SAN. The bogus certificate is rightly being rejected after your patch.