I'm trying to connect to IoTHub using Micronaut MQTT. I've a valid client key and certificate as well as the IoTHub-ca-cert.
In my application.yml, I've the following config:
mqtt:
client:
server-uri: ssl://<iothub-name>.azure-devices.net:8883
client-id: <device-id>
user-name: <iothub-name>.azure-devices.net/<device-id>/?api-version=2021-04-12
ssl:
certificate:
classpath:curl_est_crt.pem
private-key:
classpath:curl_est_key.pem
certificate-authority:
classpath:iothub.pem
But if I try to send a message to the IoT-Hub, it fails with the following exception
io.micronaut.http.server.RouteExecutor - Unexpected error occurred: Error instantiating bean of type [io.micronaut.mqtt.v5.intercept.MqttIntroductionAdvice]
Message: Implementation specific error.
Caused by: org.eclipse.paho.mqttv5.common.MqttException: Implementation specific error.
at org.eclipse.paho.mqttv5.client.internal.ExceptionHelper.createMqttException(ExceptionHelper.java:32)
at org.eclipse.paho.mqttv5.client.internal.ClientState.notifyReceivedAck(ClientState.java:1074)
at org.eclipse.paho.mqttv5.client.internal.CommsReceiver.run(CommsReceiver.java:153)
at io.micronaut.core.propagation.PropagatedContext.lambda$wrap$3(PropagatedContext.java:211)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
I've read that IoTHub requires TLSv1.2. Is this standard for micronaut or do I have to set this somewhere? (Or am I completely wrong and something else is causing this error? (I can't debug it because then I get a timeout...))
I know that somehow I could use the device-sdk but I need to authenticate via x509 certificates and I couldn't figure out how to set this up.
It looks like you are using MQTT v5. (org.eclipse.paho.mqttv5.common.MqttException
) An Azure IoT hub only supports MQTT v3.1. An "implementation error" would sound like a likely error message in that scenario. It also appears likely that the X.509 authentication was successful.