Sparkplug B clients cannot access EventGrid MQTT broker

Question

Hi,

Following the article on Sparkplug B support for EventGrid, I wanted to demo the functionality with an MQTT publisher and subscriber following the Sparkplug B specification.

I generated two X.509 certificates signed by a self-signed certificate and uploaded the CA and signed certificates to my EventGrid namespace. One certificate represented the publisher, one represented the subscriber. I allowed publishes and subscribes on all topics for all clients and added the two clients, using the SHA1 fingerprint of each X.509 certificate as the thumbprint (and validation scheme for the certificate).

Both clients were able to connect using test clients (mqttx and MQTT Explorer), each able to publish and subscribe to Sparkplug B topics and send arbitrary binary over the topic. However, when trying to connect using the "real" publisher and subscriber, I'm unsuccessful. The publisher (an IoT device using embedded C to connect through cellular) is unable to make a connection to EventGrid at all, timing out despite being able to connect and publish to other brokers (i.e., AWS IoT Core and Mosquitto). No firewall is active on the Azure EventGrid namespace. The subscriber (a .NET application) requires a PFX be used to connect to the broker. Converting the PEM certificate/key pair with the CA attached using OpenSSL is unsuccessful; the TLS handshake succeeds but the initial CONNECT packet fails on an authorization failure, despite the PEM certificate being successful on the test clients.

Could anyone give me insight as to why a test client might work with both added clients, but the IoT device and .NET application fail with a timeout and authorization failure, respectively? Please let me know if you need any more details and I'd be happy to give as much as I can.

Thank you.

Answer 1

Hi Colin McClure,

Thank you for posting your question in the Microsoft Q&A forum

The issue where your real publisher IoT device and .NET subscriber cannot connect to the Azure Event Grid MQTT broker with Sparkplug B support, despite test clients working fine, likely involves differences in certificate handling, TLS handshake, and MQTT CONNECT authorization specifics on the Azure side.

Common causes and insights:

1. Certificate Format and Chain:

The test clients like MQTTX and MQTT Explorer may be more lenient or automatically handle certificate chains and formats.

Your IoT device and .NET app require proper PFX format with the entire certificate chain included (CA + intermediate + client cert + private key).

Converting PEM to PFX must include the full chain and private key; any missing link or mismatch can cause authorization failures or connection timeouts.

Test clients are often more tolerant or automate cert handling while production IoT devices and .NET apps require exact certificate chain formatting, thumbprint matching, and supported network/TLS configurations. Troubleshooting involves ensuring PFX correctness, matching thumbprints, network setup, and checking Azure Event Grid logs.

 Reference

Support for Sparkplug B in Azure Event Grid MQTT Broker - Azure Event Grid | Microsoft Learn

MQTT (PubSub) Broker - Azure Event Grid | Microsoft Learn

I hope the provided answer is helpful,

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members. 

Thank you.

Answer 2

Re the "initial CONNECT packet fails on an authorization failure", I had that issue due to the subscriber (primary host application) not being able to publish to the spBv1.0/STATE topic which it does on connection ({online:true}) and for its LWT {{online:false}). So due to the timing in the logs it looks like my client cert was being rejected but it was actually connecting successfully and then immediately being disconnected with an authorisation failure error as it couldn't publish to the topic.

A subtle difference to an authentication error that you should get with any cert issue

As test clients usually don't set a LWT they didn't have this issue and were happily connected.

Fix in my case was making sure the subscriber also had permissions to publish.