mbedTLS: BADCERT_CN_MISMATCH on https://1.1.1.1 with curl+mbedtls

[busylog]

Maintainer: @stangri
Environment: openwrt 22.03.2 raspberry pi 3 bcm2710

Description:

curl -V
curl 7.85.0 (aarch64-openwrt-linux-gnu) libcurl/7.85.0 mbedTLS/2.28.1 nghttp2/1.44.0
Release-Date: 2022-08-31
Protocols: file ftp ftps http https mqtt
Features: alt-svc HSTS HTTP2 IPv6 Largefile MultiSSL SSL threadsafe

opkg list-installed|grep curl
curl - 7.85.0-6.1
libcurl4 - 7.85.0-6.1

curl https://1.1.1.1/ -v
* Cert verify failed: BADCERT_CN_MISMATCH
curl: (60) Cert verify failed: BADCERT_CN_MISMATCH
More details here: https://curl.se/docs/sslcerts.html

note: https://one.one.one.one/ works. ubuntu with openssl works.

limited by mbedTLS?

[busylog]

seems the blocker is at Mbed-TLS/mbedtls#2906

the remaining question: net/curl/Config.in says default LIBCURL_MBEDTLS.
blame leads to 0a65e4c

[stangri]

Sorry, what's the actual curl issue you're reporting?

[neheb]

curl+mbedtls apparently does not work with numerical domains. Sounds like mbedtls should be fixed rather than curl.

@gstrauss any input on this?

[gstrauss]

Mbed-TLS/mbedtls#6473 was closed with a pointer to Mbed-TLS/mbedtls#5082

I'll try to read through these this week:
Mbed-TLS/mbedtls#2906
Mbed-TLS/mbedtls#5082

At first (really quick) glance, extending mbedtls to handle this might be a small change in library/x509_crt.c:x509_crt_check_san() to handle MBEDTLS_X509_SAN_IP_ADDRESS in addition to MBEDTLS_X509_SAN_DNS_NAME, plus adding tests to the mbedtls test suite.

[gstrauss]

@neheb I submitted a PR to mbedtls in Mbed-TLS/mbedtls#6475

Since the PR is a feature addition, it is unlikely to be backported to mbedtls 2.28.1. However, I have checked that the patches apply cleanly to mbedtls 2.28.1, so you are are welcome to see if those patches allow curl with (patched) mbedtls to access 1.1.1.1 without BADCERT_CN_MISMATCH.

Note: my PR above does require a modern system which provides inet_pton(), which is true of modern openwrt, but not necessarily true of all embedded systems environments. I expect that the mbedtls team will request any number of portability changes before the PR might be accepted into mbedtls 3.x

[stangri]

Updated the title to reflect the current status of the issue. If the patch is needed, it would be against the OpenWrt version of mbedtls, not curl, right?

[neheb]

Yes

[neheb]

@busylog did you test this?

[stangri]

@busylog can you still reproduce with updated mbedtls?