subjectAltName IP:X.X.X.X address not recognized, CN verification fails

[klvnptr]

Summary

subjectAltName IP:X.X.X.X address not recognized, so I need to include DNS:X.X.X.X in the server cert otherwise mbedtls will throw a MBEDTLS_X509_BADCERT_CN_MISMATCH error.

System information

Mbed TLS version (number or commit id): v2.16.9 (bundled with esp-idf v4.3)
https://github.com/espressif/mbedtls/tree/99c88bb7bd7c2d91c6873abd6e6d5ee04f4f164c
Operating system and version: esp-idf v4.3 on ESP32
Configuration (if not default, please attach mbedtls_config.h):
Compiler and options (if you used a pre-built binary, please indicate how you obtained it):
Additional environment information:

Expected behavior

It should be enough to add only a "IP:127.0.0.1" subjectAltName X509 V3 certificate extension to a self signed server cert so CN verification succeeds.

https://www.openssl.org/docs/man1.1.1/man5/x509v3_config.html

Actual behavior

I need to add a DNS:127.0.0.1 subjectAltName extension as well, otherwise mbedtls throws a MBEDTLS_X509_BADCERT_CN_MISMATCH error.

Steps to reproduce

create CA:

openssl genrsa -out ca.key 2048
openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca-cert.pem -subj '/CN=test-server'

create server cert:

openssl req -newkey rsa:2048 -nodes -days 3650 -keyout server-key.pem -out server-req.pem \
  -subj '/CN=192.168.1.1' -addext "subjectAltName = IP:192.168.1.1"
openssl x509 -req -days 3650 -in server-req.pem -out server-cert.pem -CA ca-cert.pem -CAkey ca-key.pem \
  -CAcreateserial -extfile <(printf "subjectAltName=IP:192.168.1.1")

use the generated server files in your server. and use the ca-cert.pem in mbedtls client.

CN verification fails with MBEDTLS_X509_BADCERT_CN_MISMATCH

but this works:

create CA:

openssl genrsa -out ca.key 2048
openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca-cert.pem -subj '/CN=test-server'

create server cert:

openssl req -newkey rsa:2048 -nodes -days 3650 -keyout server-key.pem -out server-req.pem \
  -subj '/CN=192.168.1.1' -addext "subjectAltName = IP:192.168.1.1,DNS:192.168.1.1"
openssl x509 -req -days 3650 -in server-req.pem -out server-cert.pem -CA ca-cert.pem -CAkey ca-key.pem \
  -CAcreateserial -extfile <(printf "subjectAltName=IP:192.168.1.1,DNS:192.168.1.1")

now everything works correctly.

Additional information

[ronald-cron-arm]

Thanks for your report. From a look at the x509 code it seems that the IP address type of an X.509 v3 Subject Alternative Name is not handled by the library while the DNS type is handled. Thus I am labeling it with "enhancement" and not "bug".

[klvnptr]

Thanks for your reply. Hope you guys can quickly make this enhancement :)

[klvnptr]

Do you guys take any pull requests for this?

[ronald-cron-arm]

A PR to address this issue is more than welcome. Thanks in advance. Adding the label "help wanted" to make that explicit.

[heymikid]

I have followed your documentation and the example on how to add iPAddress to the verification of subject alternative names by mbedTLS.

In your documentation, you write that the function  x509_crt_verify_name  may need to be altered.

I am finding that in fact, the function  x509_crt_check_san  is the function that needs to be altered for the case of iPAddress, as it only checks for MBEDTLS_X509_SAN_DNS_NAME at the moment (mbedTLS release 3.3) and does not have a case for MBEDTLS_X509_SAN_IP_ADDRESS. 

In addition, I do not use the network of mbedTLS, but another network stack, so there is no elegant way now to supply the (externally obtained) IP address to mbedTLS for verification purposes (similar to mbedtls_ssl_set_hostname). Furthermore, a method to check the actual IP vs the one specified in the subject alt name is also required (I did not find one).

I would love it if a solution to this would find its way into the next release.

I have just added, in addition to what is documented in the link I have mentioned, the following code, and have successfully passed the negotiation with an IP in the subject alt name Excuse me for the crude additions not conforming to the mbedTLS coding style:

static bool was_x509_ip_address_ever_set = false;
static uint8_t ip_address[4] = { 255, 255, 255, 255 };

void my_addition_to_mbedtls_ssl_set_ip_address(uint8_t *ip)
{
was_x509_ip_address_ever_set = true;
memcpy(ip_address, ip, 4);
}

int x509_crt_check_ip(const mbedtls_x509_buf *name)
{
if (was_x509_ip_address_ever_set && name->len == 4 &&
ip_address[0] == name->p[0] &&
ip_address[1] == name->p[1] &&
ip_address[2] == name->p[2] &&
ip_address[3] == name->p[3])
{
return 0;
}

return -1;

}

/*

• Check for SAN match, see RFC 5280 Section 4.2.1.6
  */
  static int x509_crt_check_san( const mbedtls_x509_buf *name,
  const char *cn, size_t cn_len )
  {
  const unsigned char san_type = (unsigned char) name->tag &
  MBEDTLS_ASN1_TAG_VALUE_MASK;

  /* dNSName */
  if( san_type == MBEDTLS_X509_SAN_DNS_NAME )
  return( x509_crt_check_cn( name, cn, cn_len ) );

  /*iPAddress */
  if ( san_type == MBEDTLS_X509_SAN_IP_ADDRESS )
  return( x509_crt_check_ip( name ) );

  /* (We may handle other types here later.) */

  /* Unrecognized type */
  return( -1 );
  }

[gilles-peskine-arm]

@heymikid We are not currently planning to work on this issue. However, if you make a pull request that conforms to our standards (passes the CI testing, doesn't make incompatible API changes, adds a test for the new feature), there's a good chance that it can be in the next release.

[gstrauss]

PR #6475 X509 crt verify SAN iPAddress with code and tests back in Oct 2022.

It would seem that the mbedtls team has forgotten. :\

[heymikid]

I am glad you found it. I was going to engage this soon once I had some free time. Michael

…

On Thu, Feb 2, 2023, 02:19 Glenn Strauss ***@***.***> wrote: PR #6475 <#6475> X509 crt verify SAN iPAddress with code and tests back in Oct 2022. It would seem that the mbedtls team has forgotten. :\ — Reply to this email directly, view it on GitHub <#5082 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIAV5A555QDMYT4J26ZGUW3WVL4PPANCNFSM5GDXDRGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[AndrzejKurek]

#7436 is now merged and should handle this issue.
@klvnptr - is it possible for you to check if this issue is resolved?

[klvnptr]

hey @AndrzejKurek sorry, i don't work on this project anymore :( so i don't have the environment to test it out. thanks for your understanding

[gilles-peskine-arm]

#7436 implements the requested features. I can't see any gaps between the implementation and the feature request here, so I believe this issue is resolved.