MQTT - Running through Port 443 (IT Security)

We are encountering some IT security concerns w.r.t. MQTT port requirements and were wondering if we could assign it to Port 443 (typically used for HTTPS) as this is generally open for Outbound traffic by IT from the Edge device. Can this be done and not conflict with other Ignition components that use 443?

Do you have any recommendations to avoid security concerns with IT?

Many thanks in advance, Chris

Typically in a production environment port 443 would be used for the Ignition Gateway Web UI port. However, if you don’t want to use it for that (or anything else) there is no reason you couldn’t use it for MQTT. You’d just need to change your server URLs in the Transmission and Engine configuration as well as the listening port for MQTT Distributor (assuming you are using Distributor as your MQTT Server).

Thanks Wes for the response. Perhaps your response above answer my question (which is that both HTTPS and MQTT can NOT share the same port at the application layer), but just to be sure…I had posted Help Desk tick with Ignition regarding our question, and this was there response:

Thank you for the in-depth information on your background and question. It sounds like you’d need to use Application-Layer Protocol Negotiation (ALPN), so you can determine whether HTTPS or MQTT will be used over port 443. This should be possible with v4.0.8 of the MQTT module by Cirrus Link. According to the latest update notes by Cirrus Link, ALPN should be supported in Ignition 8. Ignition 8.x Compatible Release Notes - MQTT Modules for Ignition 8.x - Confluence I recommend contacting Cirrus Link support (Contact Support - Cirrus Link Solutions - Worldwide - United States) if you have additional questions about how to use this ALPN with the MQTT modules as they are better equipped to answer questions as the developers of that module. If you are still having trouble with the module after speaking with Cirrus Link, you can reach me by replying to this email or you can call in and reference ticket #25591.

FYI: My original question to Ignition was:

Our application uses MQTT for data transport (Ignition Transmission, Distributor and Engine) using a Cloud version of Ignition as the Distributor/Engine and On Premise Edge Ignition for Transmission . The Cloud is also where users go to view Perspective views. We have certain clients that are very particular about inbound/outbound port assignments on firewalls. So I have the following question…

Background Info:

A “normal” installation would use Port 8883 (MQTT SSL/TLS) for Outbound MQTT traffic from an Edge Ignition up to the Cloud, so we would need IT to allow this Firewall Outbound port to be configured open. In some cases, the IT department will NOT allow Port 8883 to be open for Outbound traffic, but WILL allow Port 443 to be open (as the default for HTTPS traffic).

Question :

If we configure the MQTT Port to use Port 443 at the Edge, will the Cloud version of Ignition be able to arbitrate Perspective (HTTPS) traffic from MQTT traffic at the Application Layer ? (Since the Cloud will need to BOTH support Perspective (HTTPS) and MQTT traffic.) In other words, does Ignition provide Layer 7 protocol arbitration (i.e. HTTPS vs MQTT). If not, is there any remedy for this requirement or acceptable option that we could propose for these IT security restrictions?

I’m not sure if Ignition supports this - I would guess probably not but maybe somebody at IA could answer. I know some of our existing customers were using ALPN with our modules and AWS IoT Core.

Thanks Wes. Unfortunately, I am in a “circular reference” as Ignition suggested I confirm with Cirrus guys.

I think there are really two sides to this question. I can confirm that MQTT Transmission does support ALPN extensions as a client. However, I don’t know if Ignition supports ALPN as a server. I would guess it probably doesn’t but IA would have to confirm that part of the question.

I’ve never seen any reference to ALPN supported on Ignition server-side. I suspect you will need a shim application in like nginx to handle the ALPN/SSL negotiation and proxy the traffic back to the proper server application behind it.