ESP-TLS
When testing RTOS SDK mqtt/ssl_mutual_auth with ESP8266, the server connection failed. Why?
The failure of SSL connection may due to insufficient memory of ESP8266.
Please use the master version of ESP8266-RTOS-SDK to test this example, since it supports dynamic memory allocation in menuconfig so as to reduce the usage of memory peak. The specific action is: menuconfig ->
Component config->mbedTLS-> (type “Y” to enable)Using dynamic TX /RX buffer-> (type “Y” to enable)Free SSL peer certificate after its usage-> (type “Y” to enable)Free certificate, key and DHM data after its usage.
Can ESP HTTPS skip the server certificate check?
Yes, if you enable the following options in menuconfig.
Menu path: (Top)->Component config->ESP-TLS->Allow potentially insecure options
Menu path: (Top)->Component config->ESP-TLS->Allow potentially insecure options->Skip server certificate verification by defaultBesides, make sure that the
cert_pemmember variable is not set in theesp_http_client_config_tstructure. Otherwise, the server certificate will still be verified with this CA certificate.If you want to test HTTP OTA at the same time, you need to enable the
Menu path: (Top)->Component config->ESP HTTPS OTA->Allow HTTP for OTAoption in menuconfig.
How to set the esp_tls_conn_read API in ESP-TLS to non-blocking mode? Or is there any other way to implement non-blocking?
You can set
non_blockto true in theesp_tls_cfg_tstructure inesp_tls.hto achieve non-blocking.Alternatively, you can call
esp_transport_connect_asyncto achieve non-blocking.
What are the TLS versions supported by ESP-IDF?
The recommended TLS protocol in ESP-IDF is the Mbed TLS protocol.
ESP-IDF v5.0 and later no longer support SSL 3.0, TLS 1.0 and TLS 1.1, but only support TLS 1.2 and TLS 1.3.
Why does the “mbedtls_ssl_handshake returned -0x7200” error occur during the SSL handshake?
The 0x7200 error is caused by the following reasons:
MBEDTLS_SSL_IN_CONTENT_LEN is too small, generally less than the maximum 16 K
Insufficient memory
The server refuses the ESP connection and the sent SSL record is incomplete. You need to capture the packet and check it. For details, please refer to Espressif Systems Wireshark User Guide.
When accessing the MQTTS Broker using IP, the error MBEDTLS_ERR_X509_CERT_VERIFY_FAILED occurs, but communication can be successfully carried out under the same conditions in testing tools like MQTTX. What could be the reason?
The issue might be due to a mismatch in the CN field. This can be bypassed by setting the member variable skip_cert_common_name_check to True to skip the CN check.
How to solve the issue of insufficient memory during a TLS handshake?
When memory is insufficient, it needs to be optimized. You can refer to Minimizing RAM Usage. If the module is equipped with external PSRAM, it needs to be correctly configured to use this memory.
What do the error codes 0x6900 and 0x7600 represent during a TLS handshake?
0x6900 (MBEDTLS_ERR_SSL_WANT_READ): This usually indicates that the operation would be blocked because there is temporarily no data in the TCP receive buffer. It is not necessarily an error but rather a signal that more data needs to be received.
0x7600 (MBEDTLS_ERR_SSL_PRIVATE_KEY_REQUIRED): This indicates that the required private key or pre-shared key has not been set. For two-way authentication, please ensure that the client has configured the correct private key.
When implementing HTTPS on ESP32, how to resolve the issue that the server certificate chain is different from what is obtained by the PC browser?
Try enabling more detailed mbedtls debug information on ESP32 to obtain the certificate chain sent by the server during the TLS handshake process, and compare it with the certificate chain obtained from the browser.
How to resolve the issue of certificate parsing failure when using ESP32?
First, you should check whether the certificate format complies with the X509 standard, and ensure that there are no issues with the certificate chain. In addition, enabling the log function of mbedtls can help diagnose the problem.