I use ESP32 ESP-IDF example to try connect to HiveMQ cloud but I get the following error
I have tested my CA certification file, username, password and client ID by successfully connecting via MQTT explorer application. Any ideas what might be the problem ?
These are my settings
const esp_mqtt_client_config_t mqtt_cfg = {
.broker = {
.address.uri = CONFIG_BROKER_URI,
.verification.certificate = (const char *)mqtt_eclipseprojects_io_pem_start
},
.credentials ={
.username= "my_username",
.client_id= "ESP32_95989e", // << you can ommit this line. client ID is constructed and sent automatically
.authentication.password = "my_password"
}
};
To confirm, has this device been able to connect successfully in the past? Additionally, could you please share as much configuration detail as you feel comfortable with? I’d like to see the way the host to connect to is configured.
In the event that there is a certificate issue occurring, we also have a thread here that has some details regarding certificate configuration for ESP32 devices.
I have only downloaded the example code from ESP-ID. The link is here
Apart from the basic configuration settings for the ESP32 board (flash,Xtal,wifi user/pass etc) I haven’t changed anything. I only updated the connection settings for TSL like shown in my previous post.
I have seen the link you sent. That’s where I downloaded the certification file.
To confirm, was the configuration changed to utilize this new certification file?
Based on the configuration screenshot provided originally, it looks as though the .verification.certificate is being assigned mqtt_eclipseprojects_io_pem_start, which is similar to the pem file included by and configured with the project by default.
To confirm, is your host currently defined as the fully qualified domain name for your cloud instance? This is required for proper cloud connectivity, as an IP address entry here can cause conflicts on connection attempt.
The error that we are currently receiving on connection attempt is a certificate rejection, specifically MBEDTLS_ERR_X509_CERT_VERIFY_FAILED. This is typically caused by an invalid certificate, but you had mentioned this was tested with another client previous. Could I also have you clarify which client was used for testing that saw success with this certificate?
The file was tested with the MQTT explorer. I input client ID , username, password, the Cluster URL, port 8883 and the certification file and I connected fine.
I was looking to confirm if the broker URL was utilized in the configuration, or if a direct IP address had been applied in the configuration rather than the broker URL, as this will not function as expected - the FQDN (broker URL) for your cluster must be used, instead.
Reviewing the ESP-MQTT documentation, I wanted to confirm that we’ve formed the URI as-expected by the library. Specifically, as per this page, the host must be configured in the format scheme://hostname:port/path.
For our use-case, that would be mqtt://{your-broker-url}:8883.
Is this the current configuration?
This page also contains a section specifying the configuration of a certificate for TLS when using this client library.
My url is this
“mqtts://276f887f0c9540c4b3d8a6be52700425.s2.eu.hivemq.cloud276f887f0c9540c4b3d8a6be52700425.s2.eu.hivemq.cloud:8883”
In the documentation there is a structure called “esp_tls_cfg_t” which has some parameters like “certificate_len”. Do I need to change any of those?
I tried to call this structure from main.c but although esp_tls.h is included I have no access to it.
Reading through the documentation above, the following is specified :
“For secure connections with TLS used, and to guarantee Broker’s identity, the verification struct must be set. The broker certificate may be set in PEM or DER format. To select DER, the equivalent certificate_len field must be set. Otherwise, a null-terminated string in PEM format should be provided to certificate field.”
For our case here, we are using a .pem certificate. It looks like the same is done in the provided example (here), but the certificate is not directly imported - it looks to be built during execution from the .pem file. See lines 30-35 here.
I built the same code on another PC and it worked fine !
Strange I will try importing the same code that worked to my PC and check again but I doubt it’s the code
This format didn’t work though
mqtts:///username:password@xxxxxxxx.s2.eu.hivemq.cloud:8883
It worked the way I did it by adding username and password variables in the structure.Client ID is not needed, it is constructed by the code automatically.
Glad to hear the connection was able to be established! It may be worthwhile to check port access on the PC experiencing the connection troubles, though the previous connection tests seem to confirm this. There is also the potential of an errant client connection remaining, blocking the port for other clients from previous tests, though a reboot would terminate these connections.
Found the problem.Stupid mistake. I had copy-pasted the same url twice in the appropriate field in menu config but couldn’t see it because the field is too small. I realized it when I moused over the uri variable.