How to enable MQTT broker authentication logs for Azure Event Grid?

@Pawel Czop ,

Thank you for your patience. I appreciate your effort in running the previous query, and I sincerely apologize for the incorrect field names in my earlier response.I reverified the schema ref : egnfailedmqttconnections_Schema, please try the following updated Kusto query:

EGNFailedMqttConnections
| where ResultSignature == "AuthenticationError"
| project TimeGenerated, SessionName, ClientIdentity, AuthenticationType, Protocol, ResultDescription
| order by TimeGenerated desc

@Pawel Czop ,

Just checking to see if the above query works ?

yes, this worked. Thanks!

Logs appear when I use standard tools like MQTT Explorer or MQTTX, but nothing appears when I try to configure and connect from camera side.

The log I'm getting on camera side is:

Is there any possibility to look somewhere else what happened on server side in this case and what is the reason of error?

@Pawel Czop ,

Thanks for your patience. I’ve reached out to the Event Grid team, and they’re willing to investigate further. To help them check if the connection request reached the MQTT Broker, could you please provide the following details?

Event Grid Namespace Name:

Azure Region (Location):

Client ID / Client Authentication Name used while connecting:

Approximate time when the connection was attempted (including time zone):

Once I have this information, I’ll share it with the Event Grid team and update you as soon as I hear back. Appreciate your cooperation!

@Pawel Czop

Just following up to see if you had a chance to review my previous message. To assist you effectively, I would need a bit more information, such as:
Event Grid Namespace Name:

Azure Region (Location):

Client ID / Client Authentication Name used while connecting:

Approximate time when the connection was attempted (including time zone):

Providing these details will help us pinpoint the issue and offer a solution promptly. Looking forward to your response!

Event Grid Namespace Name: iotcameraeventgrid1

Azure Region (Location): Germany West Central

Client ID / Client Authentication Name used while connecting:

• my-device
• client1

Approximate time when the connection was attempted (including time zone): 17:57 CET(for my-device), 18:28 CET(for client1)

CA Cert: Cert: DigiCertGlobalRootG3.crt.pem - downloaded from DigiCert

Any news related to more detailed logs? I forgot to add that date of connectionattempts was 30.03.2025

@Pawel Czop ,
I have shared the information with the team, they are looking into it. Meanwhile could you let me know if this is registered in the EG Namespace? Also is the Client Cert and CA cert in line?

this is registered in the EG Namespace?

Answer: I assume you are asking about the clients ,y-device and client1. Yes they are both registered

Also is the Client Cert and CA cert in line?

Answer:No, CA if from microsoft page(and used by Microsoft in Azure Grid service) It is from Cert: DigiCertGlobalRootG3

And works when I use it with cilent like MQTTX also with not related client cert.

Hi Ali,

I have setup port mirroring in th switch to capture the network traffic between camera and Azure Event Grid using WireShark.

I observed that regardless of the used certificate when camera sends Client hello message, then Azure doesn't respond with Server Hello message.

I found the similar issue with WolfSSL connection described here:

https://learn.microsoft.com/en-us/answers/questions/2156873/how-to-debug-wolfssl-connection-with-azure-event-g

There it was potential reasone identified as Cipher Suites offered by the client in Client hello.

In my case camera offers the following:

It seems at least 4 are supported by Azure(referring to IoT Hub doc, as specific doc for Event Grid not yet exist).

Please investigate the issue and confirm if my hypothesis is correct?

Please also inform why server does not return Server Hello during TLS handshake?

Adding Wireshark logs as attachment of bigger imagesazure2.pngazure1.png

@Pawel Czop ,

We’ve reviewed the logs and found that the connection is failing due to the absence of a client authentication name in the CONNECT packet. When MQTT clients use X.509 certificate authentication, the client authentication name is typically provided in the Username field of the CONNECT packet.

Alternatively, the name can be extracted from the certificate itself if configured accordingly. However, in your case, the following was observed:

Client certificate info:
X509Info {
  peer_cert: X509 {
    serial_number: "CA73E1F5171CB4807AAAA6CD3404A19F",
    issuer: [organizationName = "MqttBlogAppSamplesCA", commonName = "MqttBlogAppSamplesCA Intermediate CA"],
    subject: [commonName = "client1-authn-ID"],
    subject_alt_names: [client1-authn-ID],
    not_before: Mar 30 16:14:17 2025 GMT,
    not_after: Jul 8 16:14:10 2025 GMT
  },
  peer_cert_chain: None
}

And the connection attempt resulted in the following error:

Connection attempt failed, error: Connect: Bad request: No client authentication name provided
Result type: ClientError
Signature: Connect-BadRequest

You can optionally choose to extract the client authentication name from the certificate itself by selecting one or more alternative sources below.

Action Required: Please update the client configuration to include the authentication name, typically passed in the Username field, and retry the connection.

Let us know once this is done .

Hi Ali,

Are you sure you analysed the proper connection attempt?

If yes, please provide me teh timestamp of the analysed network traffic in CET time.

Please be informed that I did some tests with the same ceritficate before a and after provided timings, with and wuthout user name.

But from camera I provided username.

Please also note my update of the case form 07.04, where I sent you the logs from Wireshark proving that Azure does not respond properly after 'Client Hello' message with 'Server Hello'.

This part is before sending CONNECT packet, because it is TLS handshake negotiation and Client sends it certificate after getting proper 'Server Hello'

Please double-check and confirm if you analysed my network logs.

@Pawel Czop ,

We followed up with our Product Group (PG) team regarding the issue, and here is the latest update:

For the past one week, all connect, publish, and subscribe operations against the “iotcamereventgrid1” namespace have been successful.

Could you please confirm if you are still experiencing the issue on your end? If not, we’ll consider the case resolved. Otherwise, we’re happy to continue investigating further based on your feedback.

Yes, I still experience the issue. And as metioned I provided you the logs which prove the problem. I asked for analysis TLS handskake with occurs BEFORE CONNECT and fails. What you see with CONNECT, publish and subscribe packets come NOT from camera but from MQTTX client tool.

The same issue was described in this post:

https://learn.microsoft.com/en-us/answers/questions/2156873/how-to-debug-wolfssl-connection-with-azure-event-g

Conclusion was that(which is also present in my case) client does not send 'server_name' extension(SNI) in CLIENT HELLO packet for TLS handshake.

Can you confirm that it is mandatory to send this extension in CLIENT HELLO frame?

If yes, where it is written in Azure documentation?