mbedTLS fails SSL handshake using certificate with alternative name (SAN)

[RichPiano]

I am - once again - trying to connect to my MQTT mosquitto broker on a Raspberry Pi. I have tried it in the past and overcame the error "The certificate Common Name (CN) does not match with the expected CN" by adapting certificate access rights on the broker, so on esp32 clientside there wasn't an issue (https://www.esp32.com/viewtopic.php?f=13&t=19057). However, now the error is back. And I'm fairly certain that my broker is set up correctly on the raspberry this time.

The certificates are set up using version 3 certificate standards with the SAN extension, which allows for alternative names. We need an alternative name for our host, because our node.js script is otherwise not able to process the certificate and won't publish mqtt topics. After implementing the changes, I noticed that on the esp32 client the following error started appearing again:

Code: Select all

E (9628) esp-tls-mbedtls: mbedtls_ssl_handshake returned -0x2700
I (9638) esp-tls-mbedtls: Failed to verify peer certificate!
I (9648) esp-tls-mbedtls: verification info:   ! The certificate Common Name (CN) does not match with the expected CN
  ! The certificate is not
E (9658) esp-tls: Failed to open new connection
E (9658) TRANS_SSL: Failed to open a new connection
E (9668) MQTT_CLIENT: Error transport connect

We tested the broker using mqtt_clients and third party software (MQTT explorer from app store) which indicates that the broker works fine, as posts are routed to subscribers properly. This is also the case when we post and receive to the mosquitto broker from other devices. So we figured it should also work with the ESP32. But it doesn't.

My guess is that mbedTLS somehow doesn't support alternative names. This page seems support that (https://tls.mbed.org/kb/development/add ... me_support) but it also seems to be older information, so it might be supportet as of now.

Also, it wouldn't explain our error, because we put the same IP address in both Common Name (CN) and alternative name fields. So if mbedTLS can't parse the alternative name, the Common Name should still match. The only way I can think of why it doesn't work is that mbedTLS somehow gets confused about how to read the new version 3 certificate and fails at parsing even the common name. But I also have my doubts about that.

We would be very grateful for a hint because our product is being deployed soon and this bug keeps us from delivering punctually x_X. Thank you!

[ESP-Marius]

From my reading it seems like the SubjectAltName feature in mbedtls do not support parsing IPs: see description of

Code: Select all

x509_get_subject_alt_name

in components/mbedtls/mbedtls/library/x509_crt.c

[Michalpu]

Yes, in my opinion this is not parsing IP either

[RichPiano]

Thank you very much for your help! We switched back to pure mqtt for the moment and will soon put a suitable hostname for our raspberry pi, as this seems to be the only options (IP addresses as hostnames seem to be generally disliked by libraries).