Disable mTLS on Event Grid Namespaces port 443 for MQTT

Question

Disable mTLS on Event Grid Namespaces port 443 for MQTT

Hunter Laux 10

Typically when using MQTT via a WebSocket mTLS based authentication would not be appropriate. However, because mTLS is enabled Firefox will pop up a Window requesting to select or cancel the client certificate selection. I'd like to cancel and use JWT authentication. Cancel works, but the dialog is inappropriate and confusing. Chrome simply silent fails because websockets don't trigger chrome's certificate selection logic. You can workaround this by using an https request first prior to initiating the websocket request. Then Chrome will show the dialog, and you can cancel the certificate selection and proceed with JWT authentication. The problem is the certificate selection dialog leads to a lot of confusion.

There should be a way to disable mTLS on port 443, so that browsers don't request a certificate from the user. I would keep it enabled on 8883. The *.ts.eventgrid.azure.net host supports both the websocket MQTT and a TCP based MQTT. I only want to disabled mTLS for the websocket MQTT port, so it's usable in the browser.

Is there a way to disable mTLS on port 443?

Rakesh Mishra 2,265 Reputation points Microsoft External Staff Moderator

2025-10-03T08:15:46.5066667+00:00
Hi Hunter Laux,
Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

In Event Grid namespaces, client authentication settings are applied at the namespace level and not per-port. Once you upload CA certificates to a namespace, the MQTT broker will request client certificates as part of the TLS handshake on all secure ports (both port 8883 for MQTT/TLS and port 443 for WebSocket/TLS). This is why browsers prompt for a client certificate dialog when you connect over WebSocket - it isn’t possible to selectively disable mTLS only for port 443.

However, there are below workaround you can try. Please refer below and let me know if any issues.

1. Use separate namespaces (recommended)

Namespace A (devices):

Upload CA certificates under MQTT broker → CA certificates.

Register clients that should connect via mTLS.

Devices connect on 8883 with certificate-based authentication.

Namespace B (browsers/web):

Don’t upload CA certificates.

Configure authentication with Entra ID or Custom JWT.

Browsers connect on 443 with token-based authentication (no certificate dialog).

This way, you preserve strong security for devices and smooth UX for browsers.

2. Use a single namespace with only token authentication (simpler, but less secure)

Remove any uploaded CA certificates (az eventgrid namespace ca-certificate delete … or via portal).

Remove any registered certificate-based clients.

Configure namespace authentication with Entra ID or Custom JWT.

Both ports (8883 and 443) will now accept only JWT/token-based authentication.

Note: This option means devices will no longer connect with mTLS, which is less secure if they’re capable of certificate authentication.

References:

https://free.blessedness.top/en-us/azure/event-grid/mqtt-client-certificate-authentication

https://free.blessedness.top/en-us/azure/event-grid/oauth-json-web-token-authentication

https://free.blessedness.top/en-us/azure/event-grid/mqtt-client-custom-jwt

https://free.blessedness.top/en-us/azure/event-grid/mqtt-client-microsoft-entra-token-and-rbac
Hunter Laux 10 Reputation points

2025-10-03T17:18:01.22+00:00
I don't have a problem with exclusively using JWT for authentication.

I configured a fresh event grid namespace.

No other configuration was modified after deployment. CA certificates and local clients remained unconfigured.

Enabled MQTT.

Configured only JWT authentication.

Connected to wss://<namespace>.ts.eventgrid.azure.net/mqtt

The certificate dialog appeared. It seems that Event Grid Namespaces still requests a client certificate even if mTLS auth is not possible.

It should be noted that browsers only show this dialog if there are candidate client certificates installed on the system. It wouldn't be reasonable to expect a user to not have client certificates installed on their system.

Rakesh Mishra 2,265 Microsoft External Staff Moderator

Hi Hunter Laux, could you please try below and share findings over Private messages.

Run these from a machine with OpenSSL (this’ll show the TLS messages during handshake)

  # 1) basic connect + show handshake messages:
  openssl s_client -connect <your-namespace>.ts.eventgrid.azure.net:443 -servername <your-namespace>.ts.eventgrid.azure.net -tls1_2 -msg
  # 2) (more structured) show the server hello / certificate request details
  openssl s_client -connect <your-namespace>.ts.eventgrid.azure.net:443 -servername <your-namespace>.ts.eventgrid.azure.net -showcerts -tlsextdebug

Commands to double-check the namespace configuration. If both below lists are empty and you still see CertificateRequest in the OpenSSL output, the request is coming from the TLS terminator / platform.

  # list CA certs
  az eventgrid namespace ca-certificate list -g <rg> --namespace-name <namespace>
  # list registered clients
  az eventgrid namespace client list -g <rg> --namespace-name <namespace>

Rakesh Mishra 2,265 Reputation points Microsoft External Staff Moderator

2025-10-08T01:22:13.94+00:00

Hi Hunter Laux, following up to see if you had a chance to check my previous response. Please do let me know if you're still facing the issue and need any further assistance on this.

1 answer

Your answer

Hunter Laux 10 Reputation points

2025-10-03T17:18:01.22+00:00

I don't have a problem with exclusively using JWT for authentication.

I configured a fresh event grid namespace.

No other configuration was modified after deployment. CA certificates and local clients remained unconfigured.

Enabled MQTT.

Configured only JWT authentication.

Connected to wss://<namespace>.ts.eventgrid.azure.net/mqtt

The certificate dialog appeared. It seems that Event Grid Namespaces still requests a client certificate even if mTLS auth is not possible.

It should be noted that browsers only show this dialog if there are candidate client certificates installed on the system. It wouldn't be reasonable to expect a user to not have client certificates installed on their system.
Rakesh Mishra 2,265 Reputation points Microsoft External Staff Moderator

2025-10-06T10:31:35.1433333+00:00

Hi Hunter Laux, could you please try below and share findings over Private messages.

Run these from a machine with OpenSSL (this’ll show the TLS messages during handshake)
# 1) basic connect + show handshake messages: openssl s_client -connect <your-namespace>.ts.eventgrid.azure.net:443 -servername <your-namespace>.ts.eventgrid.azure.net -tls1_2 -msg # 2) (more structured) show the server hello / certificate request details openssl s_client -connect <your-namespace>.ts.eventgrid.azure.net:443 -servername <your-namespace>.ts.eventgrid.azure.net -showcerts -tlsextdebug

Commands to double-check the namespace configuration. If both below lists are empty and you still see CertificateRequest in the OpenSSL output, the request is coming from the TLS terminator / platform.
# list CA certs az eventgrid namespace ca-certificate list -g <rg> --namespace-name <namespace> # list registered clients az eventgrid namespace client list -g <rg> --namespace-name <namespace>
Rakesh Mishra 2,265 Reputation points Microsoft External Staff Moderator

2025-10-08T01:22:13.94+00:00

Hi Hunter Laux, following up to see if you had a chance to check my previous response. Please do let me know if you're still facing the issue and need any further assistance on this.

Answer 1

Hi Hunter Laux,

the mTLS handshake on port 443 is causing a confusing user experience in browsers, and you're right, it's not appropriate for a websocket JWT flow.

unfortunately, for the azure event grid namespace service, the mTLS configuration is a global setting for the entire namespace. there is currently no way to disable mTLS on port 443 while keeping it enabled on port 8883. the security profile is applied to the namespace's FQDN, affecting all ports.

this is a known friction point for browser based MQTT over websockets clients. the client certificate prompt is a standard browser behavior when a server requests a certificate, even if the client never intends to provide one.

your workaround of making an initial HTTPS request to cache the 'cancel' decision in chrome is a clever one, but it's not a real solution.

your best course of action here is to provide this feedback directly to the azure event grid product group. this is a user experience limitation that they need to be aware of. you can use the 'feedback' option in the azure portal or post on the official azure feedback forums to request the ability to configure mTLS per port.

there is no setting to disable mTLS on port 443 only. your only option is to use the workarounds you've found and provide feedback to microsoft requesting this as a new feature.

regards,

Alex

and "yes" if you would follow me at Q&A - personaly thx.
P.S. If my answer help to you, please Accept my answer

https://ctrlaltdel.blog/

Hunter Laux 10 Reputation points

2025-10-03T17:19:17.9666667+00:00

Is there a global toggle somewhere? I would like to use this setting.

Share via

Disable mTLS on Event Grid Namespaces port 443 for MQTT

1 answer

Your answer