# TLS SNI and Version Incorrect from Gateway on Ignition 8.1

**URL:** <https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [August 18, 2025, 7:56pm UTC](https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905 "2025-08-18T19:56:15Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![19tb21](https://avatars.discourse-cdn.com/v4/letter/1/0ea827/32.png) [@19tb21](https://forum.inductiveautomation.com/u/19tb21)\
**Post date:** [August 18, 2025, 7:56pm UTC](https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905/1 "2025-08-18T19:56:15Z")

</div>

I am having a strange issue with system.net.HTTP calls to an api endpoint. It works from console in designer on my windows machine but fails from gateway script context. The root cause appears to be that during TLS negotiation the Ignition Gateway does not send SNI. It also for whatever reason only tries TLSv1.2. I have pcaps that show that the TCP handshake completes and then at Hello Client the endpoint rejects it (because no SNI is sent by gateway). I have tried to set the java property during the event script

`from java.lang import System`  
`System.setProperty("jsse.enableSNIExtension", "true") System.setProperty("jdk.tls.client.protocols", "TLSv1.3"`)

but it still tries to do the wrong TLS negotiation

![image](https://us1.discourse-cdn.com/inductiveautomation/optimized/3X/3/0/3029fddf484be8f2b123602f9a50c8cad1c3569e_2_690x19.png)

from the console script it has no problem:

![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/d/ad75e2d05e16d3014a5e2a1c6604efe819c74ece.png)

So to summarize, the Gateway is picking the wrong TLS version, and not sending over SNI. It is not a networking problem because I can see the traffic on 443 is allowed, and the endpoint definitely has the public address range whitelisted.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 18, 2025, 7:58pm UTC](https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905/2 "2025-08-18T19:58:27Z")

</div>

These calls aren't going to the same destination IP address. There's probably a proxy or network/firewall in the middle of one of these but not the other, or some other networking difference.

---

<div class="post-metadata">

**Author:** ![19tb21](https://avatars.discourse-cdn.com/v4/letter/1/0ea827/32.png) [@19tb21](https://forum.inductiveautomation.com/u/19tb21)\
**Post date:** [August 18, 2025, 8:00pm UTC](https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905/3 "2025-08-18T20:00:04Z")

</div>

Yes that is correct, but not the problem. Even the the console script will get routed to different IP. The networking side public IP Address range is allowed to hit the endpoint but the actual endpoint address changes. We are using hostname in api call.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 18, 2025, 8:14pm UTC](https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905/4 "2025-08-18T20:14:08Z")

</div>

What version of Ignition is this?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 18, 2025, 8:20pm UTC](https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905/5 "2025-08-18T20:20:04Z")

</div>

Also, since I have access to your pcaps via support

> [@19tb21](#):
>
> The root cause appears to be that during TLS negotiation the Ignition Gateway does not send SNI

> [@19tb21](#):
>
> I have pcaps that show that the TCP handshake completes and then at Hello Client the endpoint rejects it (because no SNI is sent by gateway)

The one connection attempt to any of the IP addresses associated with this hostname in the captures you provided _does_ use SNI.

> [@19tb21](#):
>
> It also for whatever reason only tries TLSv1.2.

It opens with an identical TLS handshake/hello to your success capture from the machine with the Designer, including inidicating it supports both TLS 1.3 and TLS 1.2, and prefers TLS 1.3.

The only difference is Wireshark identifies it as TLS 1.3 because it has a subsequent response from the server where the server chose TLS 1.3.

---

<div class="post-metadata">

**Author:** ![19tb21](https://avatars.discourse-cdn.com/v4/letter/1/0ea827/32.png) [@19tb21](https://forum.inductiveautomation.com/u/19tb21)\
**Post date:** [August 18, 2025, 8:45pm UTC](https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905/6 "2025-08-18T20:45:02Z")

</div>

I think you are confusing pcaps, I sent both successful and not successful. There is never any instance I have seen in the pcaps where it succeeds to send hello client from gateway with SNI. Only the successful one from the console uses SNI. This is Ignition 8.1.47

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 18, 2025, 8:45pm UTC](https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905/7 "2025-08-18T20:45:45Z")

</div>

The pcap I'm looking at is called `gatewayscope_wrongtls2.pcapng`.

The only other one I saw on the ticket was `working_from_designer_console2.pcapng`.

---

<div class="post-metadata">

**Author:** ![19tb21](https://avatars.discourse-cdn.com/v4/letter/1/0ea827/32.png) [@19tb21](https://forum.inductiveautomation.com/u/19tb21)\
**Post date:** [August 18, 2025, 9:28pm UTC](https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905/8 "2025-08-18T21:28:43Z")

</div>

Oh you are right the raw pcap does have it, I was just using Wireshark UI without looking at the raw txt file… oops. Ok I can look back the endpoint again with this info. TLS 1.2 is supported by the endpoint so version shouldn’t matter.

---

<div class="post-metadata">

**Author:** ![19tb21](https://avatars.discourse-cdn.com/v4/letter/1/0ea827/32.png) [@19tb21](https://forum.inductiveautomation.com/u/19tb21)\
**Post date:** [August 18, 2025, 10:28pm UTC](https://forum.inductiveautomation.com/t/tls-sni-and-version-incorrect-from-gateway-on-ignition-8-1/109905/9 "2025-08-18T22:28:46Z")

</div>

Fixed, we didn’t actually have this host applied with static NAT like I thought we did. No problem, gateway works fine.
