# 8.1 and 8.3 endpoint validation issues **URL:** \ **Category:** Ignition\ **Tags:** opcua\ **Created:** [September 10, 2026, 1:58am UTC](https://forum.inductiveautomation.com/t/8-1-and-8-3-endpoint-validation-issues/117039 "2026-09-10T01:58:06Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![tyler2](https://avatars.discourse-cdn.com/v4/letter/t/71e660/32.png) [@tyler2](https://forum.inductiveautomation.com/u/tyler2)\ **Post date:** [September 10, 2026, 1:58am UTC](https://forum.inductiveautomation.com/t/8-1-and-8-3-endpoint-validation-issues/117039/1 "2026-09-10T01:58:06Z")
I have gone through [OPC-UA Client connection issues - Ignition - Inductive Automation Forum](https://forum.inductiveautomation.com/t/opc-ua-client-connection-issues/79799/27) and a few others. My vendor's documentation provides the following cause & "resolution" for the endpoint mismatch upon connection. What solution is needed to avoid the mismatch error in my customer's 8.1 environment and my 8.3 Maker? From the other post, it sounds like I should only need to enable None for security (everything else is base OPC UA config), but that doesn't seem to work in 8.3. In both systems, the server cert is trusted by the client, and the client trusts the server. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/e/2e811565d1e2d7c2f17a579b79b52d6989af1709.png) Using my system as an reference, I can only specify the endpoint and a couple other options with the vendor software. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/1/014d35b7fd973ba02fb67c5ef66a93d62330d445.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/e/0ea7af0870ac57e16cc7488aa768d716f7beef8f.png) The only main difference between my environment and the customer's is that the client software is installed on the gateway server (whereas mine is setup on another server), so the bind address is localhost and the client is connecting to localhost:port (which works with UaExpert). ---
**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:** [September 10, 2026, 3:15am UTC](https://forum.inductiveautomation.com/t/8-1-and-8-3-endpoint-validation-issues/117039/2 "2026-09-10T03:15:18Z")
This isn't a configuration problem in Ignition, it's a bug in the software you're using. We can confirm that if you're able to provide a Wireshark capture. We've seen this bug in later versions of the OSI PI adapter or connector (forget which it's called), but the bug is from the underlying SDK they use, so in theory other clients using that SDK could experience the same issue. ---
**Author:** ![tyler2](https://avatars.discourse-cdn.com/v4/letter/t/71e660/32.png) [@tyler2](https://forum.inductiveautomation.com/u/tyler2)\ **Post date:** [September 10, 2026, 12:40pm UTC](https://forum.inductiveautomation.com/t/8-1-and-8-3-endpoint-validation-issues/117039/3 "2026-09-10T12:40:27Z")
[Trace.zip](https://forum.inductiveautomation.com/uploads/short-url/6yHWLd2OO4eZDxWQYTn2gFzawNi.zip) (2.0 KB) I'd agree it's an issue with the newer versions - it's been a few years since I've tried connecting AVEVA to read from Ignition, which did work the last time. I have attached the filtered output of Wireshark from the AVEVA side. I'm not sure of what exactly to look for, but I can see some of the requests and responses. I let it go through the initial connection and two connect/disconnect cycles. ---
**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:** [September 10, 2026, 1:32pm UTC](https://forum.inductiveautomation.com/t/8-1-and-8-3-endpoint-validation-issues/117039/4 "2026-09-10T13:32:01Z")
This capture contains only a single packet. You'd need to get the whole thing, with security turned off, to verify. If this is OSI PI though you might as well not bother. If you're a paying customer, call their support and complain. We reported this to them like a year ago. Separately, one of our devs who used to work there reached out to a PM and let them know that way as well. Multiple customers have run into this. I'm not sure they care. ---
**Author:** ![tyler2](https://avatars.discourse-cdn.com/v4/letter/t/71e660/32.png) [@tyler2](https://forum.inductiveautomation.com/u/tyler2)\ **Post date:** [September 10, 2026, 3:48pm UTC](https://forum.inductiveautomation.com/t/8-1-and-8-3-endpoint-validation-issues/117039/5 "2026-09-10T15:48:45Z")
That's my bad - when I saved the filtered output, I selected the wrong option. I did have security enabled before, so this also removes that. I'll have to see what they say then (I'm assuming the trace below will confirm what you have in all these other issues), but until then it sounds like my options are to use an older Adapter or to use MQTT instead. [filtered.zip](https://forum.inductiveautomation.com/uploads/short-url/q2eqLJkqaVDSbHu1Cq2kOaSeEOW.zip) (7.1 KB) ---
**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:** [September 10, 2026, 5:08pm UTC](https://forum.inductiveautomation.com/t/8-1-and-8-3-endpoint-validation-issues/117039/6 "2026-09-10T17:08:58Z")
AFAIK using an older adapter is what other customers end up doing. and yes, looking at the capture, it's the same issue. They are implementing this logic incorrectly: [Parameters – OPC Unified Architecture - Part 4: Services](https://reference.opcfoundation.org/specs/OPC-10000-4/5.7.2.2#:~:text=A%20Client%20shall%20compare,by%20the%20Client). ---
**Author:** ![tyler2](https://avatars.discourse-cdn.com/v4/letter/t/71e660/32.png) [@tyler2](https://forum.inductiveautomation.com/u/tyler2)\ **Post date:** [September 11, 2026, 5:03pm UTC](https://forum.inductiveautomation.com/t/8-1-and-8-3-endpoint-validation-issues/117039/7 "2026-09-11T17:03:43Z")
Can't say I'm surprised. Without them knowing the OPC UA server vendor, they're saying they're right and the server is wrong. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/c/2cbd6cbd13d5ce6e71976e3a57210f5e084e86ca.png) ---
**Author:** ![tyler2](https://avatars.discourse-cdn.com/v4/letter/t/71e660/32.png) [@tyler2](https://forum.inductiveautomation.com/u/tyler2)\ **Post date:** [September 14, 2026, 12:54pm UTC](https://forum.inductiveautomation.com/t/8-1-and-8-3-endpoint-validation-issues/117039/8 "2026-09-14T12:54:13Z")
As a follow-up - > _According to the information we received from past cases, it was stated that Ignition OPC UA servers don't seem to provide the certificate information in the CreateSession response, so the connection fails._ > > _Could you please confirm this behaviour for me and check with your developer if there is any way for the certificate information to be provided?_ Is there anything from the trace you can provide to indicate the server side is doing what it should? I'd like to get AVEVA to address the problem. ---
**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:** [September 14, 2026, 12:56pm UTC](https://forum.inductiveautomation.com/t/8-1-and-8-3-endpoint-validation-issues/117039/9 "2026-09-14T12:56:30Z")
It’s not supposed to provide the certificate in the CreateSessionResponse. The spec passage I linked to says as much, and it says the client shall not require it. That's the whole issue here - they are requiring the certificate be there when the spec explicitly says they shall not.